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

Christian Mauderer christian.mauderer at embedded-brains.de
Tue Apr 3 14:43:20 UTC 2018


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,
>>>
>>> I took the liberty to rebase the patches to the latest master. See the
>>> two following v3 mails. I'll take a look at the configuration based on
>>> these patches.
>>>
>>> I think that you wanted to make i386 tests. After that it might would be
>>> a good idea to commit them. What do you think?
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>
>> Hello Chris,
>>
>> just noted: The freebsd-to-rtems.py (with -R) doesn't work anymore. I'll
>> fix that.
>>
>> Maybe it would be a good idea to develop that (and the config options)
>> on a branch (on a user specific repo on git.rtems.org) and post it for
>> review? At least it's a bigger change.
>>
>> Best regards
>>
>> Christian
>>
> 
> Most likely there will be some more changes till the configuration is
> implemented. So I created a branch called ticket-3351 for review here:
> https://git.rtems.org/christianm/rtems-libbsd.git/log/?h=ticket-3351
> 
> I added a fix for the freebsd-to-rtems.py to that branch.
> 

Hello Chris,

may I ask you about some points:

1. I've put some thoughts into the configuration file format. My first
idea to use ini files for it had a big disadvantage: It's hard to
include one ini file into another. So I have tried to use a python
script as a configuration file instead. What do you think of that
approach? My current implementation is mainly in this commit on the
ticket-branch:
https://git.rtems.org/christianm/rtems-libbsd.git/commit/?h=ticket-3351&id=0504219600d6a6cac8775a8e95ebe56f473a9991

Note that also the config can be read, this branch currently doesn't
build (see 2.).

2. I'm struggling to build two versions of libbsd in one waf call.
Currently the two configurations have increased the number of files that
have to be build by the factor two. Beneath the point that waf has
problems building the same file twice, I'm not really happy with that
because it increases the build time a lot. I would prefer some solution
that only builds files twice that have different options. Would you
agree with that or would you go for building each file for each config?

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,
I can just add a build variant suffix. Do you happen to know where that
directory comes from? 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.

Best regards

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


More information about the devel mailing list