How to build librtemscpu.a and librtemsbsp.a in the future?

Sebastian Huber sebastian.huber at
Tue Mar 27 06:17:26 UTC 2018

On 27/03/18 01:15, Chris Johns wrote:
> On 26/03/2018 17:32, Sebastian Huber wrote:
>> On 25/03/18 05:20, Chris Johns wrote:
>>> On 24/3/18 1:27 am, Sebastian Huber wrote:
>>>> Hello,
>>>> I tried to consolidate the cpukit This ended up in the following
>>>> problem. The content of librtemscpu.a depends on the CPU port. This is currently
>>>> done via a non-standard
>>>> _SUBDIRS = ../@RTEMS_CPU@
>>>> construct.
>>> Where is this? I cannot find it.
> I am confused, the link's version does not have '../'?

Sorry, I should have used copy and paste.

> [...]
>> I am not sure how we want to proceed with the build system stuff.
> It is becoming more and more important this work starts to happen. I am happy to
> make the change to waf if we can attract the funding to do it.
> I have pushed the existing build system as far as I want to without major
> refactoring. I would like to test a recent autoconf and automake to see if we
> can move to a recent version. The recent perl issues highlights the problems we
> can expect to face if we do not change.
>> Should we first clean up the existing build system first?
> I have no interesting in a "clean up" or a refactor. I have played with it
> enough in recent times with the parallel build and pre-install work to know it
> is a deep pit with much gnashing of teeth, rolling of eyes, and terrible roars.

I think there are some issues left which need a clean up:


* Command line defines

* Host tools should be removed or moved to rtems-tools

> The major issue we have is the time configure takes. I you play with the
> rtems-bsp-builder and the --jobs option you will get an idea. If you look at
> Joel's latest build:
> jobs is '--jobs=6/12' which means run 6 parallel RTEMS BSP builds and use 12
> cores per build. We can do this because of the time configure takes using a
> single core. I think Joel has 24 cores on this box. This setting builds a BSP
> every 18 seconds on average which is impressive but it is a hack.

Yes, I think we need only two configure runs. One in the top-level and 
one in the BSP (for the BSP options).

>> Should it be possible to run an
>> old and new build system in parallel for a certain time?
> Yes it should be and this is the plan. The removal of pre-install fixed a build
> issue exposed with parallel building but it also served the more important role
> of making a change to waf simpler.
> chris

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
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list