[PATCH v2 1/2] waf: Support building from libbsd.py directly from waf.

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

> 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