[PATCH v2 1/2] waf: Support building from libbsd.py directly from waf.
christian.mauderer at embedded-brains.de
Wed Apr 4 07:14:19 UTC 2018
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:
> 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 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.
Was that an agree to the preference of build speed over complexity or
was it an agree to defaulting to one config?
>> - 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
>> - 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.
embedded brains GmbH
Herr Christian Mauderer
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.
More information about the devel