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