Am 04.04.2018 um 09:00 schrieb Chris Johns: > 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.
I didn't want to put blame onto any component alone. But in that case I think that I can only decide between these two: Faster builds for multiple libraries versus slower builds but an easier build system configuration. I'm still not sure which is better. > >> 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. Was that an agree to the preference of build speed over complexity or was it an agree to defaulting to one config? > >> 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. A build bot would be great some times. In the ideal case some CI system similar to "Travis CI" like on github. But I think currently everyone of us is lacking the time to set it up. > > Chris > -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
