Re: automake and AC_CONFIG_FILES($foo)

[Harlan Stenn]

> | 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