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:


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

The builder then runs the jobs for a specific build configuration:


This is basically reduces to a list of RTEMS configure commands with different

> 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 

> 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.


> 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. 

devel mailing list

Reply via email to