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

[Sebastian Huber]

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 Makefile.am. 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.
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/Makefile.am#n1
>>
> 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:

* Use of RTEMS_RELLDFLAGS

* 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:
>
> https://lists.rtems.org/pipermail/build/2018-March/000554.html
>
> 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 embedded-brains.de
PGP     : Public key available on request.

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