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

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

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