multiple AM_INIT_AUTOMAKEs cause problems

[Christopher Sean Morrison]

Hello,

I've have a section in a configure.ac that attempts to dynamically 
determine whether or not to enable dependency tracking and it seems to 
be causing quite a bit of hassle on at least some versions of automake. 
 Basically, I have the following:

AC_MSG_CHECKING([whether dependency tracking should be enabled])
if test -d $srcdir/CVS ; then
        AC_MSG_RESULT(it should)
        AM_INIT_AUTOMAKE
else
        AC_MSG_RESULT(it should not)
        AM_INIT_AUTOMAKE([no-dependencies])
fi

The intent is that if it's not a CVS checkout, I want dependency 
tracking disabled by default for faster builds.  Otherwise, it should 
be enabled.

The most problematic systems arise from the first AM_INIT_AUTOMAKE 
getting substituted, but the second is not so that am__api_version is 
never set and several utilities are not checked (awk, install, ..).  
Interestingly enough, the build will still complete successfully.  
However, if it attempts to run aclocal or automake again (e.g. after 
editing a Makefile.am), it ends up trying to run the nonexistent 
"aclocal-" and "automake-" commands since am__api_version was only set 
for the true part of the if-test.  (Shouldn't some sort of sanity check 
prevent that from happening?)

I've tried using a make variable for dynamically setting the 
AUTOMAKE_OPTIONS in the Makefile.am, but it does not like the variable 
in the list.  Similarly, if I pull out the AM_INIT_AUTOMAKE from the 
if/fi block and try feeding it a variable, it's similarly unrecognized 
(aborts):

if test -d $srcdir/CVS ; then
        blah=""
else
        blah="no-dependencies"
fi
AM_INIT_AUTOMAKE([$blah])

Any suggestions on how I might be able to get it to 
automatically/dynamically set the automake option at configure time?  
Should manually setting $enable_dependency_tracking in itself before 
AM_INIT_AUTOMAKE be sufficient?  And/or perhaps calling AM_DEP_TRACK 
directly?  Thanks in advance for any advice.

Cheers!
Sean