From 030be95eaedc9cf582f5a47507521840fa5bdded Mon Sep 17 00:00:00 2001 From: Alexandre Duret-Lutz Date: Wed, 1 Aug 2001 16:19:56 +0000 Subject: [PATCH] * m4/auxdir.m4: More comments. --- ChangeLog | 4 ++++ m4/auxdir.m4 | 49 +++++++++++++++++++++++++++++++++++-------------- 2 files changed, 39 insertions(+), 14 deletions(-) diff --git a/ChangeLog b/ChangeLog index a0fa08c8..a6b5bc5d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2001-08-01 Alexandre Duret-Lutz + + * m4/auxdir.m4: More comments. + 2001-07-31 Richard Boulton Raja R Harinath diff --git a/m4/auxdir.m4 b/m4/auxdir.m4 index a99f76ee..746cec05 100644 --- a/m4/auxdir.m4 +++ b/m4/auxdir.m4 @@ -1,21 +1,42 @@ # 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 calls a tool -# from the auxiliary directory. The problem is that $srcdir (and therefore -# $ac_aux_dir as well) can be either an absolute path or a path relative to -# $top_srcdir, depending on how configure is run. This is pretty annoying, -# since it makes $ac_aux_dir quite unusable in subdirectories: in the top -# source directory, any form will work fine, but in subdirectories a relative -# path needs to be adjusted first. -# - calling $top_srcdir/$ac_aux_dir/missing would succeed if $ac_aux_dir was -# relative, but fail if it was absolute. -# - conversly, calling $ac_aux_dir/missing would fail if $ac_aux_dir was -# relative, and succeed on absolute paths. +# $ac_aux_dir to `$srcdir/foo'. In other projects, it is set to +# `$srcdir', `$srcdir/..', or `$srcdir/../..'. # -# Consequently, we define and use $am_aux_dir, the "always absolute" -# version of $ac_aux_dir. +# Of course, Automake must honor this variable whenever it calls a +# tool from the auxiliary directory. The problem is that $srcdir (and +# therefore $ac_aux_dir as well) can be either absolute or relative, +# depending on how configure is run. This is pretty annoying, since +# it makes $ac_aux_dir quite unusable in subdirectories: in the top +# source directory, any form will work fine, but in subdirectories a +# relative path needs to be adjusted first. +# +# $ac_aux_dir/missing +# fails when called from a subdirectory if $ac_aux_dir is relative +# $top_srcdir/$ac_aux_dir/missing +# fails if $ac_aux_dir is absolute, +# fails when called from a subdirectory in a VPATH build with +# a relative $ac_aux_dir +# +# The reason of the latter failure is that $top_srcdir and $ac_aux_dir +# are both prefixed by $srcdir. In an in-source build this is usually +# harmless because $srcdir is `.', but things will broke when you +# start a VPATH build or use an absolute $srcdir. +# +# So we could use something similar to $top_srcdir/$ac_aux_dir/missing, +# iff we strip the leading $srcdir from $ac_aux_dir. That would be: +# am_aux_dir='\$(top_srcdir)/'`expr "$ac_aux_dir" : "$srcdir//*\(.*\)"` +# and then we would define $MISSING as +# MISSING="\${SHELL} $am_aux_dir/missing" +# This will work as long as MISSING is not called from configure, because +# unfortunately $(top_srcdir) has no meaning in configure. +# However there are other variables, like CC, which are often used in +# configure, and could therefore not use this "fixed" $ac_aux_dir. +# +# Another solution, used here, is to always expand $ac_aux_dir to an +# absolute PATH. The drawback is that using absolute paths prevent a +# configured tree to be moved without reconfiguration. AC_DEFUN([AM_AUX_DIR_EXPAND], [ # expand $ac_aux_dir to an absolute path -- 2.43.5