Re: [PATCH] build: Update configure.ac to support the latest automake.
On 02/04/2018 13:27, Chris Johns wrote: > > I have managed to solve this issue with a hack but another more critical issue > has appeared related to the way the tests are structured and share code as > sources rather than a library. The `subdir-objects` breaks the testsuite when > building with a parallel build. > This post documents the reason we cannot currently update automake unless we update the testsuite somehow and avoid the current pattern being used. I have only looked at the fstests so I am not sure if this pattern is repeated elsewhere. The template like approach for the fstests conflicts with the recent automake model and how we use or abuse it combined with our parallel build support which could also be considered another abuse. I feel we need to update automake to mitigate the dependency risk older versions of automake has or may have with other dependent host programs, for example perl. The analysis is ... The file system tests are per file system (imfs, jffs2, dosfs, and rfs) and there is a support directory for each file system type plus the general support directory with a common Init. We have sub-directories for each test and the support code and the latest automake generates a warning indicating we need to add the option 'subdir-objects'. This however implies a non-recursive make and we have sub-directories and a recursive make [1] and changing that is just too difficult. Setting the 'subdir-objects' option places the .o file in a build tree equivalent path to the source. Building the tests in parallel results in the object file being built and linked once for each time it is referenced in a Makefile.am. A parallel build with parallel recursive makes builds the tests in parallel which results in the tests building and linking the same object file(s) at the same time. Obviously this is not a good idea because what a single test builds and what it links can and do differ. It is possible to build the per file system support as a library however the general support is being built for each per file system library and so again we have another layer of sharing a C file and the possibility of a library containing the wrong version of an object file. We need to consider this approach to test code. I appreciate the approach reduces the number of places we have however this dependence on the build system _and_ the preprocessor could be minimally altered to achieve almost the same result. For example 'Init' in fstest_support.c could be 'FS_Init' with 'FILESYSTEM' and 'test()' passed in. That would remove one of the problematic dependences we have. This combined with a per file system support library might work. Another simpler hack would be adding a C file called 'support.c' to each effected test that includes the needed C source. I am not sure if this is acceptable. It is a really horrible hack and I will always disown it if we head down this path. Chris [1] https://autotools.io/automake/nonrecursive.html ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Update configure.ac to support the latest automake.
On 2/4/18 12:18 pm, Chris Johns wrote: > On 1/4/18 2:02 pm, Chris Johns wrote: >> On 1/4/18 1:58 pm, Joel Sherrill wrote: >>> Great job! >> >> Thanks. Simpler than I expected. >> > > Testing shows this change is not enough, more is needed to make this stuff > work. > > The error is: > > config.status: error: in > `/opt/work/chris/rtems/kernel/bsps/xilinx_zynq_zedboard/arm-rtems5/c/xilinx_zynq_zedboard/testsuites/samples': > config.status: error: Something went wrong bootstrapping makefile fragments > for automatic dependency tracking. Try re-running configure with the > '--disable-dependency-tracking' option to at least be able to build > the package (albeit without support for automatic dependency tracking). > See `config.log' for more details > > I cannot find too much about this and what is happening. I can see the > `leaf.cfg` link is not being made and so I can only guess something related to > `RTEMS_BSP_CONFIG_SUBDIR()` and `AC_CONFIG_SUBDIRS()` has changed which means > the `leaf.cfg` is not being made before samples is being configured. > I have managed to solve this issue with a hack but another more critical issue has appeared related to the way the tests are structured and share code as sources rather than a library. The `subdir-objects` breaks the testsuite when building with a parallel build. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Update configure.ac to support the latest automake.
On 1/4/18 2:02 pm, Chris Johns wrote: > On 1/4/18 1:58 pm, Joel Sherrill wrote: >> Great job! > > Thanks. Simpler than I expected. > Testing shows this change is not enough, more is needed to make this stuff work. The error is: config.status: error: in `/opt/work/chris/rtems/kernel/bsps/xilinx_zynq_zedboard/arm-rtems5/c/xilinx_zynq_zedboard/testsuites/samples': config.status: error: Something went wrong bootstrapping makefile fragments for automatic dependency tracking. Try re-running configure with the '--disable-dependency-tracking' option to at least be able to build the package (albeit without support for automatic dependency tracking). See `config.log' for more details I cannot find too much about this and what is happening. I can see the `leaf.cfg` link is not being made and so I can only guess something related to `RTEMS_BSP_CONFIG_SUBDIR()` and `AC_CONFIG_SUBDIRS()` has changed which means the `leaf.cfg` is not being made before samples is being configured. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Update configure.ac to support the latest automake.
On 1/4/18 1:58 pm, Joel Sherrill wrote: > Great job! Thanks. Simpler than I expected. > > What needs to be done to give any more confidence? > Some testing. The change was simple so I do not expect too many issues. > When do we upgrade automake in the RSB? > Patch posted. > And fwiw I would like to see the last three POSIX .h files moved to newlib. > The > next newlib bump already will fix a couple of pthread prototypes. OK. Chris ps: You should be having a log weekend off! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
