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

[Chris Johns]

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 ?

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

Chris