autoconf/228: autoconf/228: AC_CONFIG_COMMANDS problem

[autoconf]

The following reply was made to PR autoconf/228; it has been noted by GNATS.

From: address@hidden
To: address@hidden,address@hidden
Cc: 
Subject: autoconf/228: AC_CONFIG_COMMANDS problem
Date: Fri, 27 Dec 2002 06:22:09 -0500

 >Number:         228
 >Category:       autoconf
 >Synopsis:       AC_CONFIG_COMMANDS problem
 >Confidential:   no
 >Severity:       critical
 >Priority:       high
 >Responsible:    akim
 >State:          open
 >Quarter:        
 >Keywords:       
 >Class:          sw-bug
 >Submitter-Id:   net
 >Arrival-Date:   Fri Dec 27 06:22:09 -0500 2002
 >Cases:          
 >Originator:     Eric Sunshine
 >Release:        2.57
 >Organization:
 
 >Environment:
 All
 >Description:
 In Autoconf 2.57 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 commands 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.  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 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_MKDIR_P([foo])])
 
 Unfortunately, this solution 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.
 >How-To-Repeat:
 
 >Fix:
 Unknown
 >Unformatted: