automake-patches
[Top][All Lists]
Advanced

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

more auxdir.m4 comments


From: Alexandre Duret-Lutz
Subject: more auxdir.m4 comments
Date: 01 Aug 2001 17:57:25 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

The comment before auxdir.m4 missed some failures (in fact
$top_srcdir/$ac_aux_dir/missing almost never works). I've also
added some comments about why it's not possible to include
$(top_srcdir) in $am_aux_dir.

Index: ChangeLog
from  Alexandre Duret-Lutz  <address@hidden>

        * m4/auxdir.m4: More comments.

Index: m4/auxdir.m4
===================================================================
RCS file: /cvs/automake/automake/m4/auxdir.m4,v
retrieving revision 1.1
diff -u -r1.1 auxdir.m4
--- m4/auxdir.m4 2001/07/20 01:25:14 1.1
+++ m4/auxdir.m4 2001/08/01 15:53:32
@@ -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

-- 
Alexandre Duret-Lutz




reply via email to

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