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

[Christian Mauderer]

Am 04.04.2018 um 07:28 schrieb Chris Johns:
> This is one way, another below which I think will be easier and better.
> 
> The build system handles builds for a range of arch/bsp pairs here:
> 
> https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems.py#n182
> 
> I would play with the `bsp_configure` option to `configure()`:
> 
>  https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems.py#n269
> 
> and see what happens if you play with:
> 
>   env = conf.env.derive()
> 
> and:
> 
>   conf.setenv(ab + '/ipv6', env)
> 
> setting the env back at the end to:
> 
>   conf.setenv(ab, env)
> 
> I have no idea if you stack env's.
> 
> Maybe you can create a new conf environment for +1 config variants setting the
> derived env with the path to the INI file. If you only have one config to build
> use the conf env passed to `bsp_configure()`.
> 
> If you look into this file and the waf examples etc you will see the
> `build(bld)` does not have any loops.

Hello Chris,

these points have put me into the right direction. I think I now have
understood a lot more about how the variants work. Please note that this
mail doesn't have a question in it. It is more thought as a reference in
case I need to recall that in a few years for the next change ;-)

The build variants have two parts:

1. There is a loop in init that creates sub-classes of the BuildContext,
CleanContext, InstallContext and UninstallContext. These get a command
like "build-arm-rtems5-atsamv" and a variable "variant" with the content
"arm-rtems5-atsamv". Beneath that all "build-arm-rtems5-atsamv" and
similar command are collected so that they can be executed together on a
build.

2. In the configure, there is the part that you mentioned: The derived
environment with a name like "arm-rtems5-atsamv".

I'm not sure how waf knows about the derived context classes or how it
puts the variant and the contexts together. I assume that it happens
using the name. But that shouldn't really be relevant for my use case as
long as it works.


Now for the build process, we have multiple stages:

1. waf configure

For that one, waf calls the options, init and configure function of the
wscript. After that everything in the environment should be set up to
build the variants. All functions are only single functions.

2. waf build

If used with two BSPs this is more or less an alias to a
build-<every-bsp-that-is-configured>. For example:

   waf build-arm-rtems5-atsamv build-arm-rtems5-beagleboneblack

For each of these, the build-function in the wscript is called one time
using a different environment parameter.


For the current set up that means that I can't pass information via the
builder object directly. Either I'll have to pass information via the
environment or I have to select the correct builder based on the
environment. I'll evaluate these two options.

Best regards

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