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

[Sebastian Huber]

On 28/03/18 02:35, Chris Johns wrote:
> On 27/03/2018 17:17, Sebastian Huber wrote:
>> 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'
> I have not looked into this stuff. What is happening with these flags and these
> *.rel files?
>
> Is this some sort of component system using incremental objects ?

I think it is a hack to enable the use of LIBADD. It was used mainly by 
the libcpu.

>
>> * Command line defines
>>
> Lets leave that to the ticket on this topic.
>
>> * Host tools should be removed or moved to rtems-tools
> Agreed.
>
>>> 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).
>>
> That would be nice. I suggest we resolve how the tree looks in the other thread
> before we proceed. It would provide clarity for this work and a solid direction.

The host tools are a blocking point for me to do anything with the 
configure.ac files.

Another issue are the complicated test program Makefile.am. We have the 
optional BSP-specific post-link command which transforms an .exe file 
(ELF) into a .ralf file. The RTEMS tester duplicates this feature 
somehow. How would waf deal with this post-link step? Is there a 
standard support for a post-link step in Automake?

The "make dist" is broken?

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