On 04/04/2018 16:35, Christian Mauderer wrote: > Am 04.04.2018 um 08:20 schrieb Chris Johns: >> 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: >>> 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. >> > > Yes, something like that. Not really a easy to create and easy to > understand construction.
I did this with the BSP builder. It loads the configuration information from the INI files: https://git.rtems.org/rtems-tools/tree/tester/rt/check.py#n922 Take a look at this function and INI files to see the way it loads configuration into the data structure from the INI data. I see what you need as a variation of this. The builder then runs the jobs for a specific build configuration: https://git.rtems.org/rtems-tools/tree/tester/rt/check.py#n1403 https://git.rtems.org/rtems-tools/tree/tester/rt/check.py#n1411 https://git.rtems.org/rtems-tools/tree/tester/rt/check.py#n1377 This is basically reduces to a list of RTEMS configure commands with different options. > So it's a trade off. Build speed versus build > system complexity. The complexity is driven as much by the source management as the actual building. > Normally I would go for build speed due to the fact that we most likely > build much more often than touching the build system. On the other hand > the build system is already quite hard to understand. So another > alternative could be interesting: Set only one config (and not all) as > default so that for most cases only this one is build. Agreed. > Advantages: > - faster default build > - a first-time user has no problem to decide which one he wants > - no problem when doing a `waf install` which library should be installed > > Disadvantage: > - most developers will build only one variant during development and > most likely forget to test with all variants before sending the patch > I see providing no configure option as the "Advantages" and an option as a way to enable more configurations. In theory a buildbot would build all for us. Sigh. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel