On 28/03/18 02:35, Chris Johns wrote:
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 ?
I think it is a hack to enable the use of LIBADD. It was used mainly by
the libcpu.
* 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.
The host tools are a blocking point for me to do anything with the
configure.ac files.
Another issue are the complicated test program Makefile.am. We have the
optional BSP-specific post-link command which transforms an .exe file
(ELF) into a .ralf file. The RTEMS tester duplicates this feature
somehow. How would waf deal with this post-link step? Is there a
standard support for a post-link step in Automake?
The "make dist" is broken?
--
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
