Recursion using automake behaves unexpectedly

1
votes

I have an autotools setup coexisting with a traditional Makefile in a single repository. In order to avoid overwriting ./Makefile, I have set configure.ac to copy Makefile.in into Makefile.test.

There is a subdirectory that is managed by the generated Makefile.test. When I run 

    make -f Makefile.test clean

the script correctly enters the test directory, runs clean, and steps out of the directory. However, upon returning to the root it attempts to call clean-am, using what appears to be a plain

   make clean-am

This invokes the wrong make file, and I get the following error.

    rm -f *.lo
    make[2]: Leaving directory `/home/somedude/work_repos/some-repo/test'
    make[2]: Entering directory `/home/somedude/work_repos/some-repo'
    make[2]: *** No rule to make target `clean-am'.  Stop.
    make[2]: Leaving directory `/home/somedude/work_repos/some-rep'
    make[1]: *** [clean-recursive] Error 1
    make[1]: Leaving directory `/home/somedude/work_repos/some-repo'
    make: *** [clean] Error 2

Any help on how to solve this problem would be much appreciated.

2
makefileautotoolsautoconfautomake

2 Answers

1
votes

Rename your static makefile to something different, and generate the makefile as you normally would with the Autotools, outputting makefile or Makefile, not Makefile.test.

This is solved by not naming your Automake-generated makefile anything other than one of the recognized filename patterns, "makefile" (all lowercase) being the first and most portable. I just tried the same thing, and all it does is $(MAKE) $(AM_MAKEFLAGS) all-recursive, which expands to make all-recursive for me.

In other words, Automake cannot handle the concept of makefiles with alternate filenames, mainly because in order to generate the correct code, it would need to know about them. Since it doesn't (and possibly cannot), it is forced to assume a default makefile filename.

The ability to rename an input/output filename probably was not meant for this. It was created, if you can infer the reason from the manual's example, due to the DOS limitation of the 8.3 filename; config.h.in isn't a valid filename, so you must map the input file generating config.h to config.hin for example. Using it to rename the makefile generated from Makefile.in or whatever filename you used obviously doesn't work.

I hope this helps.

1
votes

your best bet is probably to use a filename for the Makefile, which fullfills the following criteria:

  • get's picked automatically (so you don't need to specify the -f flag)

  • overrides the default makefile

  • does not clash with Makefile (so you can keep the other makefile around)

reading man make you get:

make executes commands in the makefile to update one or more target names, where name is typically a program. If no -f option is present, make will look for the make‐files GNUmakefile, makefile, and Makefile, in that order.

so the obvious choice is to use GNUmakefile as your autotools makefile.

as long as you don't have run ./configure your filesystem tree will look like:

 Makefile
 GNUmakefile.in
 GNUmakefile.am
 configure
 [...]

so running make will call the default (legacy) makefile. after your configure-run, there will also be a GNUmakefile in the path, and make will automatically pick the new shiny autotools Makefile.

i've used this successfully to maintain two parallel make-based build systems.