AC_CONFIG_COMMANDS problem

[Eric Sunshine]

Hello,

I sent this bug report almost a year ago but never received a response, nor  
has the problem been addressed, so I thought I would try again.

In Autoconf 2.57 (all releases) and in the CVS version, there is a problem  
with AC_CONFIG_COMMANDS when it is used to create a file in a directory which  
does not already exist at the time config.status is run.  Consider the  
following configure.ac:

AC_PREREQ([2.57])
AC_INIT([myprog], [0])
AC_CONFIG_COMMANDS([foo/bar], [echo "test" > foo/bar])
AC_OUTPUT

This results in a config.status which produces these error messages:

configure: creating ./config.status
./config.status: line 1: cd: foo: No such file or directory
./config.status: line 1: cd: foo: No such file or directory
./config.status: line 1: cd: foo: No such file or directory
./config.status: line 1: cd: foo: No such file or directory
config.status: executing foo/bar commands

These errors are caused by the following lines in config.status which are  
executed right before the "foo/bar" target is invoked:

ac_abs_builddir=`cd "$ac_dir" && cd $ac_builddir && pwd`
ac_abs_top_builddir=`cd "$ac_dir" && cd ${ac_top_builddir}. && pwd`
ac_abs_srcdir=`cd "$ac_dir" && cd $ac_srcdir && pwd`
ac_abs_top_srcdir=`cd "$ac_dir" && cd $ac_top_srcdir && pwd`

The problem is that these commands are trying to change to the non-existent  
"foo" directory.

This raises the question of whether AC_CONFIG_COMMANDS should be be  
responsible for creating the "foo" directory itself before running the  
target's commands, much like AC_CONFIG_FILES will create missing directories.  
 However, considering that AC_CONFIG_COMMANDS is intended to be generic  
(that is, the target does not necessarily have to represent a file), then one  
can successfully argue that AC_CONFIG_COMMANDS should _not_ create the "foo"  
directory.  This leads to the obvious answer that the target should itself  
be responsible for creating its own directory if necessary.  Thus, a  
re-written configure.ac which creates its own output directory would appear  
as follows:

AC_PREREQ([2.57])
AC_INIT([myprog], [0])
AC_CONFIG_COMMANDS([foo/bar],
    [AS_MKDIR_P([foo])
    echo "test" > foo/bar])
AC_OUTPUT

Unfortunately, this version _also_ fails with the exact same error messages.  
 The reason it fails is because config.status still attempts to compute  
ac_abs_builddir, ac_abs_top_builddir, ac_abs_srcdir, and ac_abs_top_srcdir  
_before_ the target's commands have been invoked (before `mkdir' is issued),  
thus the problem is not solved.

One very ugly hack to work around this problem is to move the `mkdir' to  
AC_CONFIG_COMMANDS's "init-cmds", as follows:

AC_PREREQ([2.57])
AC_INIT([myprog], [0])
AC_CONFIG_COMMANDS([foo/bar],
    [echo "test" > foo/bar],
    [AS_ESCAPE(AS_MKDIR_P([foo]), [$`\])])
AC_OUTPUT

Unfortunately, this solution, though it "works", is incorrect because it  
causes "foo" to be created when _any_ config.status target is invoked, even  
though "foo" should only be created when the "foo/bar" target is invoked.   
This means that even the invocation "config.status --help" will incorrectly  
create the "foo" directory.

Note that the ugly AS_ESCAPE invocation, for this case, is required to  
guarantee that AS_MKDIR_P works correcly on platforms which do not have a  
working "mkdir -p" command.  AS_ESCAPE ensures that the variables and  
subshell environments (such as $ac_dir, $ac_dirs, `dirname`, etc.) which  
result from the expansion of AS_MKDIR_P are properly protected.  Thus, these  
variables and subshells will be evaluated correctly in the context of  
config.status, rather than in the context of configure.

I would be interested in seeing a fix for this problem.  This is a  
real-world issue which I discovered when converting the Crystal Space project  
(http://crystal.sourceforge.net/) to use Autoconf.

-- ES