[PATCH] build: Update configure.ac to support the latest automake.

[Chris Johns]

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