We recently ran into some problems with OpenAFS where the relative path to the install-sh script that Autoconf (config.status) substitutes into files on systems without a good system install program (such as Solaris) caused issues. One of those involved calling a script created by config.status in a loop that used cd, and the other was a place where our build system symlinks a makefile to another makefile in a different directory.
There is usually always some sort of build system reconfiguration or refactoring that one can do to make this work with relative paths, but it's kind of annoying. The first instinct of other project developers is to play various games with AC_CONFIG_AUX_DIR to try to force it to be an absolute path, but I'm worried we're going to do something that will break later. In doing some web searches, I see that GCC ran into the same problem and changes the value of $INSTALL in configure to use an absolute path, which is generated with `cd $srcdir ; pwd`. But there too this seems too fragile, since detecting the case of an Autoconf-set path to install-sh may fail later. So, in short, it would be very nice if there were some way to force Autoconf to use absolute paths when substituting paths to scripts in the aux directory into generated files. Is there any chance that Autoconf could add an AC_PROG_INSTALL_ABS or some other way to say that the substituted path to install-sh needs to be an absolute path? I think that's the main program affected; config.sub and config.guess are run internally by Autoconf in ways that don't have this problem, and the other helper programs are generally Automake's business and Automake handles generating the right make rules internally. (OpenAFS uses Autoconf but not Automake, as it has a large and complex build system that does some things that Automake can't easily handle, such as build kernel modules for nearly a dozen versions of UNIX.) -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
