Le 12/09/2016 à 02:41 PM, Mike Holmes a écrit : > > > On 9 December 2016 at 08:33, Nicolas Morey-Chaisemartin <nmo...@kalray.eu > <mailto:nmo...@kalray.eu>> wrote: > > > > Le 12/09/2016 à 02:18 PM, Mike Holmes a écrit : >> >> >> On 9 December 2016 at 04:41, Nicolas Morey-Chaisemartin >> <nmo...@kalray.eu <mailto:nmo...@kalray.eu>> wrote: >> >> I'm OK with this. The only issue I have with this is that it moves >> back platform/OS selection back to configure.ac <http://configure.ac> while >> I've been trying to move it out >> (https://github.com/nmorey/odp/tree/dev/generic-platforms >> <https://github.com/nmorey/odp/tree/dev/generic-platforms>). >> Shouldn't each platform select the right OS ? >> I mean linux-generic will probably always use the linux helper while >> the mppa implementation will use the right one for us (depending on the >> compilation flags). >> >> >> I would actually like to make the helpers much more independent so I am >> in line with your thinking. >> How about we just do exactly that and have helpers build completely >> independently with its own configure.ac <http://configure.ac> ? > > Won't the dependence from the platform test to the helper lib be an issue? > Splitting them up might end in a circualt dependency. > > > I am hoping to find and delete any circular dependencies that exist, the > helper should depend on the odp api, the tests and examples should depend on > the helpers > > > > Build ODP means building the tests which means building the helpers which > need ODP to be built (for odp_cpumask_* functions at least). > > I'm not sure we really need to pull them out of the ODP build system, but > simply keep the configure flexible enough so platforms can tweak/change the > settings from the platform side. > > Platform could add their own options in their configure.m4 if they need > them, or simply select the basic helper setup and export the OS. > > > Ok then I misunderstood this "Shouldn't each platform select the right OS ?" > - I agree it should. > > I added the selector "with_os" to the common configure.ac > <http://configure.ac> does that not allow it to be changed by platform if we > keep it all under one configure setup? - perhaps it can be set in a per > platform configure.m4 as you say, I need to fiddle with that. Yes my bad. It works like that. configure.m4 should be able to adjust settings depending on the option, or overwrite the value if they know better.
> > > > > > >> >> >> >> Also I think the lib should be renamed to libodphelper instead of >> libodphelper-linux. >> >> >> agree >> >> >> >> Any plans to get these patches in soon? >> >> >> with your help asap >> >> >> Should I wait for your patch to get in master, or get them in my >> patch series? >> >> >> Will work with you, let me make your suggested change to the lib and >> circle back with you on your first point. > Glad to hear it :) > > > > > -- > Mike Holmes > Program Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM SoCs > "Work should be fun and collaborative, the rest follows" >
