> | autoconf handles AC_CONFIG_FILES($foo) properly. > > But I should say it is not recommended! The documentation asks for > literals whenever it is possible.
Yes, and I agree with it in general. > | A plain invocation of "automake" rightly complains that it has no idea what > | it needs to look at, but running "automake (some list of Makefiles)" > | produces: > | > | configure.ac: 23: required file `./$foo.in' not found > | > | which seems wrong. If automake is called with explicit filename arguments > | it should ignore (or not complain) about variables in AC_CONFIG_FILES. > > What is this $foo? Don't you need to EXTRA_DIST it somewhere? I'm > asking the question because precisely, if you move to > > case $foo in > bar) AC_CONFIG_FILES(bar) ;; > foo) AC_CONFIG_FILES(foo) ;; > baz) AC_CONFIG_FILES(baz) ;; > esac > > is what Autoconf recommends, and it would solve more of your problems, > wouldn't it? I just stepped in to an existing Large project. These folks swear they will *never* do a "make dist". They have an Interesting wrapper script that produces a list of .../Makefile files for each of their several target platforms and "package configurations", and their "autobootstrap.sh" script as well as configure.in effectively source in this list of Makefiles, so they can call "automake $foo" as well as "AC_CONFIG_FILES($foo)". > I _insist_, I'm *not* asking you to change your code: I'm (i) asking for > details to understand your needs, and (ii) _suggesting_ an alternative. One of the biggest apparent hurdles is that these folks would benefit from having a single monolithic Makefile.am at the top level, as that would provide the best parallel makes, provide the best library dependency stuff, run the fastest, etc. OTOH, it would be Difficult to coordinate changes to this Makefile.am (lots of developers) and they still want the ability to run a make in a subdir. Other problems include about 160 Makefile.am's that use automake conditionals to decide if certain _PROGRAMS need to be made or not, and in many cases, which target-specific _SOURCES need to be used. I arrived just after the conversion from automake-1.4 to 1.5, and based on my current efforts I'm probably going to recommend we look at upgrading to 1.6.1 just to quiet some of the "automake does not support XXX being defined conditionally" messages. While this could also be solved by using AC_SUBST() for the selected items in configure.in, again that means moving this knowledge there and dealing with the checkin conflicts from so many developers having to mess with changing configure.in . I'm actually considering looking at keeping the Makefile.am's in each subdir and looking at AutoXport to combine this info into a top-level .xml file and then see if that .xml file can be easily converted to a Jakarta/ant build.xml file. H
