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

[Chris Johns]

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.

> 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. Is the MRI format
still alive in any MRI or Mentor products?

> 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