autoconf
[Top][All Lists]
Advanced

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

$ac_aux_dir issue (Was on address@hidden: Re: amtraces)


From: Alexandre Duret-Lutz
Subject: $ac_aux_dir issue (Was on address@hidden: Re: amtraces)
Date: 03 Feb 2001 20:01:37 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>> "Akim" == Akim Demaille <address@hidden> writes:

 Akim> "Derek R. Price" <address@hidden> writes:

[...]

 >> +    AC_CONFIG_AUX_DIR => sub { @config_aux_path = $_[2] },

 Akim> This macro gives too many problem.  Alexandre D. knows what I'm
 Akim> referring to, I'd like him to start a thread in autoconf@ about this.

[...]

I'm going to do some cut'n'paste...

The issue is shortly explained in one pending patch for automake:

| # AM_AUX_DIR_EXPAND
|
| # For projects using AC_CONFIG_AUX_DIR([foo]), Autoconf sets
| # $ac_aux_dir to ${srcdir}/foo.  In other projects, it is set to `.'.
| # Of course, Automake must honor this variable whenever it call a tool
| # from the auxiliary directory.  The problem is that $srcdir (hence
| # $ac_aux_dir) can be either an absolute path or a path relative to
| # $top_srcdir or absolute, this depends on how configure is run.  This
| # is pretty anoying since it makes $ac_aux_dir quite unusable in
| # subdirectories: on the top source directory, any form will work
| # fine, but in subdirectories relative paths needs to be adapted.
| # - calling $top_srcidr/$ac_aux_dir/missing would success if $srcdir is
| #   relative, but fail if $srcdir is absolute
| # - conversly, calling $ax_aux_dir/missing would fail if $srcdir is
| #   absolute, and success on relative paths.
| #
| # Consequently, we define and use $am_aux_dir, the "always absolute"
| # version of $ac_aux_dir.
|
| AC_DEFUN([AM_AUX_DIR_EXPAND], [
| # expand $ac_aux_dir to an absolute path
| am_aux_dir=`CDPATH=:; cd $ac_aux_dir && pwd`
| ])

I did also post more longish experiments; here they are:

| I'm using this:
|
| ~/tmp % automake --version | head -1
| automake (GNU automake) 1.4b
| ~/tmp % autoconf --version | head -1
| autoconf (GNU autoconf) 2.49b
| ~/tmp %
|
| Here is how to setup a test case:
|
| ~/tmp % mkdir test; cd test
| ~/tmp/test % mkdir tools src
| ~/tmp/test % cat > configure.in
| AC_INIT
| AC_CONFIG_AUX_DIR(tools)
| AM_INIT_AUTOMAKE(x,0)
| AC_OUTPUT(Makefile src/Makefile)
| ^D
| ~/tmp/test % cat > Makefile.am
| SUBDIRS=src
| ^D
| ~/tmp/test % cat > src/Makefile.am
| all:
|         @echo I want to call install-sh from src/, how should I do?
|         @echo $(install_sh)
|         @echo $(top_srcdir)/$(install_sh)
| ^D
| ~/tmp/test % aclocal
| ~/tmp/test % autoconf
| ~/tmp/test % automake -a --foreign
| automake: configure.in: installing `tools/install-sh'
| automake: configure.in: installing `tools/mkinstalldirs'
| automake: configure.in: installing `tools/missing'
| ~/tmp/test % find
| .
| ./tools
| ./tools/install-sh
| ./tools/mkinstalldirs
| ./tools/missing
| ./src
| ./src/Makefile.am
| ./src/Makefile.in
| ./configure.in
| ./Makefile.am
| ./aclocal.m4
| ./configure
| ./Makefile.in
| ~/tmp/test %
|
|
| Now let's try various configurations.
|
| With relative srcdir:
|
| ~/tmp/test % silent=yes ./configure             # configure -q is broken
| creating Makefile
| creating src/Makefile
| ~/tmp/test % make -s
| Making all in src
| I want to call install-sh from src/, how should I do?
| tools/install-sh
| ../tools/install-sh
| ~/tmp/test %
|
|
| With absolute srcdir:
|
| ~/tmp/test % silent=yes $PWD/configure
| creating Makefile
| creating src/Makefile
| ~/tmp/test % make -s
| Making all in src
| I want to call install-sh from src/, how should I do?
| tools/install-sh
| /home/adl/tmp/test/tools/install-sh
| ~/tmp/test %
|
| So far so good, $(top_srcdir)/$(install_sh) is always correct,
|                 $(install_sh) is always wrong.
|
|
| Let's go try VPATH builds.
|
| With relative srcdir and builddir != srcdir:
|
| ~/tmp/test % make -s distclean
| ~/tmp/test % mkdir build; cd build
| ~/tmp/test/build % silent=yes ../configure
| creating Makefile
| creating src/Makefile
| ~/tmp/test/build % make -s
| Making all in src
| I want to call install-sh from src/, how should I do?
| ../tools/install-sh
| ../../../tools/install-sh
| ~/tmp/test %
|
| With absolute srcdir and builddir != srcdir:
|
| ~/tmp/test/build % silent=yes $PWD/../configure
| creating Makefile
| creating src/Makefile
| ~/tmp/test/build % make -s
| Making all in src
| I want to call install-sh from src/, how should I do?
| /home/adl/tmp/test/build/../tools/install-sh
| /home/adl/tmp/test/build/..//home/adl/tmp/test/build/../tools/install-sh
| ~/tmp/test/build %
|
| So in these two cases it's just the converse:
|  $(top_srcdir)/$(install_sh) is wrong,
|  $(install_sh) is correct.

This is not specific to install-sh, any tool put in auxdir/ is a
potential problem.  For example gettext has to be patched to define
mkinstalldir with an absolute path in order to work properly with
AC_CONFIG_AUX_DIR and VPATH builds.  Either it can be expanded in
configure, like in m4/libintl.m4 from latest fileutils:

   if test -n "$ac_aux_dir"; then
     MKINSTALLDIRS="`CDPATH=:; cd $ac_aux_dir && pwd`/mkinstalldirs"
   fi

(this is also how MISSING is initialized by automake) or expanded
in po/Makefile.in.in as in CVS gettext:

mkinstalldirs = $(SHELL) `case "$(MKINSTALLDIRS)" in /*) echo 
"$(MKINSTALLDIRS)" ;; *) echo "$(top_builddir)/$(MKINSTALLDIRS)" ;; esac`


IMHO this is ugly and autoconf should probably settle something
so that auxdir can be used cleanly.  Since any use of $auxdir
has to be expanded, wouldn't it make sense to have autoconf
define and document $auxdir as an absolute path?

OTOH, autoconf defines @INSTALL@ using $ac_aux_dir, and $(INSTALL) is
usable anywhere.  That's because this variable has a special treatment
in config.status (it's relative path is adjusted with regard to the
depth of the generated file).  Maybe another solution would be to
provide a mean for the autoconf user to specify additional variable to
be handled likewise.

Using relative paths whenever a file from the package (such as
the files in $ac_aux_dir) is refered to seems better to me
because it allows people to move a whole tree without requiring
`make distclean'.

-- 
Alexandre Duret-Lutz



reply via email to

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