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
