How to build librtemscpu.a and librtemsbsp.a in the future?
sebastian.huber at embedded-brains.de
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:
>>>> 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@
>>> 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:
* 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:
> 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.
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