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

[Christian Mauderer]

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