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

[Sebastian Huber]

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

>
>> The wrapup/Makefile.am combines several static libraries into one
>> librtemscpu.a. With librtemsbsp.am we have a similar problem. This archive
>> unpack and re-create step seems to be a bit expensive.
> Yes this is an awkward work around. I seem to remember this is borrowed from
> automake and adapted for us. No matter where is comes from it is a hack and a
> pain to maintain. With nested makes we do not have access to the list of objects
> so we need to extract, capture and create to merge.
>
>> Why can't we use an MRI script, e.g.
>>
>> create ./sparc-rtems5/erc32/lib/librtemscpu.a
>> addlib ./sparc-rtems5/c/erc32/cpukit/librtemscpu.a
>> addlib ./sparc-rtems5/c/erc32/cpukit/score/cpu/sparc/libscorecpu.a
>> save
>> end
>>
>> ?
> If this was supported by the standard GNU script I would be more receptive but
> even then I feel it is papering over build system weaknesses.

I just searched for "merge static libraries gnu" and found this. It 
seems to work.

> Is the MRI format
> still alive in any MRI or Mentor products?

I don't know.

>
>> Would conditional Makefile.am parts be more efficient, e.g. in cpukit/Makefile.am
>>
>> if CPU_ARM
>> include score/cpu/arm/make.am
>> endif
>> if CPU_XXX
>> ...
> I think this would be a major piece of work. You would need to make sure any
> globals at the make level do not step on each other.
>
>> How would waf deal with this problem?
>>
> Efficiently. See:
>
>   https://git.rtems.org/rtems-libbsd/tree/libbsd_waf.py#n2469
>
> Chris

So, waf has a global view of the project. I think this is similar to a 
single top-level Makefile.am with various "if XXX" constructs.

I am not sure how we want to proceed with the build system stuff. Should 
we first clean up the existing build system first? Should it be possible 
to run an old and new build system in parallel for a certain time?

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