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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
