bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Relative paths for $INSTALL


From: Russ Allbery
Subject: Relative paths for $INSTALL
Date: Wed, 21 Jul 2010 14:41:41 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

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 (address@hidden)             <http://www.eyrie.org/~eagle/>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]