How to build start.o using waf?
sebastian.huber at embedded-brains.de
Fri Oct 4 06:21:26 UTC 2019
On 03/10/2019 04:32, Chris Johns wrote:
> On 3/10/19 3:30 am, Gedare Bloom wrote:
>> On Wed, Oct 2, 2019 at 5:12 AM Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>>> On 30/09/2019 15:14, Sebastian Huber wrote:
>>>> I would like to work on a new build system prototype. The idea is to use
>>>> specification items maintained by Doorstop (YAML files), a Python
>>>> configuration script and waf to build RTEMS and the tests. This is
>>>> similar to the libbsd build. The difference is that in libbsd the build
>>>> data is maintained directly in Python code (libbsd.py).
> A key design aspect is how the configuration of RTEMS is handled and maintained.
> Amar's solution provides a specific model for managing settings and specifically
> BSP options. We need a way to add options for a BSP that lets us collect,
> document and validate these settings. We need a way to query and review option
> defaults. The solution needs to be able to add and remove BSPs with minimal
> impact and this leads to being able to build a BSP that is external to the RTEMS
> source tree. There are BSPs that are private or export restricted. Another issue
> to consider is how we deprecate, update or alter options.
> I suspect we will have an iterating design around the internal design and
> implementation complexity and suitable external user work-flows.
Now is a good time to create a wish list for the new build system. I
cannot implement everything, but I can try to make a substantial initial
Doorstop is a tool to manage a directed, acyclic graph of items. Each
item has a set of attributes (key-value pairs). Some attributes are
pre-defined by Doorstop with requirements management in mind. You can
also add an arbitrary number of custom attributes. With this data
structure you can tackle a lot of problems. The items are stored in YAML
My approach would be to store all the data that defines the build in
build item files. The wscript file reads the build items, configures the
build and performs the build as specified also by command line options,
e.g. which BSP, with tests, etc. The build item files can be also used
by other tools.
A BSP is represented by a BSP build item which links to BSP option
items, object items (start.o) and file groups for librtemsbsp.a.
A BSP is just a node in the graph, you can ask for example: if I remove
this BSP item, does it create isolated items? The isolated items can be
removed if the BSP is removed. If you change an option, you can figure
out the impact, e.g. which BSP uses this option.
Since the build is driven by item files which just reside in a
directory, you can also point the build script to another directory with
items defined externally. The question is if waf is capable to build
files outside the top directory. Building externally defined stuff has a
very low priority for me. I just want to point out that there are no
fundamental obstacles with this approach.
The details of BSP options can be easily managed with specialized
attributes, e.g. type, min, max, default value, etc. We can utilize the
full power of
which is a very nice Python module. We may use
to provide services we need for this BSP (and others):
The callbacks can be stored in the items files as Python code and
imported with exec(). The callbacks need an ability to install a
post-processing handler which is invoked during the waf configure(),
e.g. to generate the linker command file based on options.
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel