Thanks, I will post to the list On 12 December 2016 at 04:31, Nicolas Morey-Chaisemartin <nmo...@kalray.eu> wrote:
> I just had a quick look and it looks good to me. > > Nicolas > > > Le 12/10/2016 à 08:29 PM, Mike Holmes a écrit : > > https://github.com/mike-holmes-linaro/odp/tree/helpers-os > > Helper lib now gets the default helper OS from the platfrom in use via > its configure.m4 > > On 9 December 2016 at 08:45, Nicolas Morey-Chaisemartin <nmo...@kalray.eu> > wrote: > >> >> >> Le 12/09/2016 à 02:41 PM, Mike Holmes a écrit : >> >> >> >> On 9 December 2016 at 08:33, Nicolas Morey-Chaisemartin <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> 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 while I've been trying to >>>> move it out (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 ? >>> >>> >>> 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 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" >> >> >> > > > -- > 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" > > > -- 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"
