On 04/04/2018 15:51, Christian Mauderer wrote: > Am 04.04.2018 um 07:28 schrieb Chris Johns: >> On 04/04/2018 00:43, Christian Mauderer wrote: >>> Am 27.03.2018 um 09:56 schrieb Christian Mauderer: >>>> Am 27.03.2018 um 09:00 schrieb Christian Mauderer: >>>>> Am 26.03.2018 um 14:59 schrieb Christian Mauderer: >>>>>> Hello Chris, >>>>>> > > Thanks for the pointers. I'll take a look at them. But from what I > currently read, that might will lead to the variant where every file is > build for every config. > > To be honest: I never tried to build multiple BSPs. I'll try that with > BSPs for the same architecture and take a look at how the files are > generated. Most likely it would be the best to use the same approach. >
If it works as we expect. I am not sure yet which is best. >>> >>> 3. That depends a little on the answer to two: >>> >>> 3a) If I build everything for every config, I could try to put the >>> objects for every config into its own subdirectory. That seems to be >>> possible somehow: We already have for example a >>> "build/arm-rtems5-atsamv" directory. If I find out how that is created, >> >> The other approach is the list of `builders` as you started to implement and >> passing into `builder.build(bld, 'ipv4-only')` a configuration label, >> something >> short and simple, that you prepend to `bld` `targets` making them unique. You >> need to update the `uses` so a config build correctly track their build >> objects. >> If you did this waf would figure out the build details. >> >> The down side is needing to manage the library name because it is a single >> build >> directory. I suppose the install can rename to libbsd and use config paths. >> I am >> not sure which way is best, what do you think? > > Like I said above, I would prefere to exclude some modules from building > multiple times. For example OpenSSL has around 700 files but it > shouldn't depend on IPv4 or IPv6 or on WiFi support. > > Disadvantage of that is that with this approach every module would have > to know which options are relevant for it and which are not. So I > wouldn't change the defines directly but instead create a list of > features that can be enabled or disabled. Yes, this is the view I had formed. > Every module then would get > this list and would have to decide for itself which defines are > necessary in that case. Yes, you end up with a dict of modules each with a list of builds where some value varies from the default. The module build list could be dict of each arg to a 'bld()' that varies from the default. You would also have a dict of libraries, the output we are after, and each library would have a list oof module builds. This way a common base module is only built once and loaded in a number of libraries. It is then a case of creating all the 'bld()'s and a 'build.stlib()' for each library providing the 'use' list of module builds it needs. > >> >> Reviewing the file: > > Please don't put too much time into review of these first patches. They > are still work in progress. Understood. It only took a moment as I was looking to see what can be done. :) > I mostly pushed them so I can get some > feedback regarding the config. Of course I'll clean up everything and > create only very few clean ones at the end. Understood. >> >>> It seems that the name is created in the >>> rtems_waf/rtems.py. But I'm not totally sure: >>> >>> https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems.py#n124 >>> >>> 3b) If I try to build only variants of files I somehow have to add a >>> suffix (or prefix) to the generated object files. I haven't found out >>> yet how I could do that. Do you know (without searching too much) >>> whether waf has such an option? If you don't know it, I'll dig deeper >>> into waf myself. >> >> I think this is the target name. If a build target is unique waf needs to >> manage >> the object file names. It has too. You can see this with a build of the same >> source with different defines or cflags. > > Odd. I had problems even with different target names. I'll try to dig > deeper into that. In the previous generated waf build I made the target names using a counter and a text label prefix: https://git.rtems.org/rtems-libbsd/tree/libbsd_waf.py#n313 As long as the target and the use match it should work: https://git.rtems.org/rtems-libbsd/tree/libbsd_waf.py#n319 https://git.rtems.org/rtems-libbsd/tree/libbsd_waf.py#n2470 Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel