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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
