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

Wed Apr 4 06:35:07 UTC 2018

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:
>>>> Am 27.03.2018 um 09:56 schrieb Christian Mauderer:
>>>>> Am 27.03.2018 um 09:00 schrieb Christian Mauderer:
>>>>>> Am 26.03.2018 um 14:59 schrieb Christian Mauderer:
>>>>>>> Hello Chris,
>>>>>>>
>>
>> Thanks for the pointers. I'll take a look at them. But from what I
>> currently read, that might will lead to the variant where every file is
>> build for every config.
>>
>> To be honest: I never tried to build multiple BSPs. I'll try that with
>> BSPs for the same architecture and take a look at how the files are
>> generated. Most likely it would be the best to use the same approach.
>>
> 
> If it works as we expect. I am not sure yet which is best.
> 
>>>>
>>>> 3. That depends a little on the answer to two:
>>>>
>>>> 3a) If I build everything for every config, I could try to put the
>>>> objects for every config into its own subdirectory. That seems to be
>>>> possible somehow: We already have for example a
>>>> "build/arm-rtems5-atsamv" directory. If I find out how that is created,
>>>
>>> The other approach is the list of `builders` as you started to implement and
>>> passing into `builder.build(bld, 'ipv4-only')` a configuration label, something
>>> short and simple, that you prepend to `bld` `targets` making them unique. You
>>> need to update the `uses` so a config build correctly track their build objects.
>>> If you did this waf would figure out the build details.
>>>
>>> The down side is needing to manage the library name because it is a single build
>>> directory. I suppose the install can rename to libbsd and use config paths. I am
>>> not sure which way is best, what do you think?
>>
>> Like I said above, I would prefere to exclude some modules from building
>> multiple times. For example OpenSSL has around 700 files but it
>> shouldn't depend on IPv4 or IPv6 or on WiFi support.
>>
>> Disadvantage of that is that with this approach every module would have
>> to know which options are relevant for it and which are not. So I
>> wouldn't change the defines directly but instead create a list of
>> features that can be enabled or disabled. 
> 
> Yes, this is the view I had formed.
> 
>> 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. So it's a trade off. Build speed versus build
system complexity.

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

> It is then a case of creating all the 'bld()'s and a 'build.stlib()' for each
> library providing the 'use' list of module builds it needs.
> 
>>
>>>
>>> Reviewing the file:
>>
>> Please don't put too much time into review of these first patches. They
>> are still work in progress.
> 
> Understood. It only took a moment as I was looking to see what can be done. :)
> 
>> I mostly pushed them so I can get some
>> feedback regarding the config. Of course I'll clean up everything and
>> create only very few clean ones at the end.
> 
> Understood.
> 
>>>
>>>> It seems that the name is created in the
>>>> rtems_waf/rtems.py. But I'm not totally sure:
>>>>
>>>> https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems.py#n124
>>>>
>>>> 3b) If I try to build only variants of files I somehow have to add a
>>>> suffix (or prefix) to the generated object files. I haven't found out
>>>> yet how I could do that. Do you know (without searching too much)
>>>> whether waf has such an option? If you don't know it, I'll dig deeper
>>>> into waf myself.
>>>
>>> I think this is the target name. If a build target is unique waf needs to manage
>>> the object file names. It has too. You can see this with a build of the same
>>> source with different defines or cflags.
>>
>> Odd. I had problems even with different target names. I'll try to dig
>> deeper into that.
> 
> In the previous generated waf build I made the target names using a counter and
> a text label prefix:
> 
> https://git.rtems.org/rtems-libbsd/tree/libbsd_waf.py#n313
> 
> As long as the target and the use match it should work:
> 
> https://git.rtems.org/rtems-libbsd/tree/libbsd_waf.py#n319
> https://git.rtems.org/rtems-libbsd/tree/libbsd_waf.py#n2470
> 
> 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.