Re: AC_CONFIG_FILES assumes that build directories have sibling in the source tree

[Akim Demaille]

>>> "Akim" == Akim Demaille <address@hidden> writes:
 > [...]

 Akim> Nope, it does not "work fine": it contains a hidden failure:

 Akim> rm -Rf test
 Akim> mkdir test
 Akim> cd test
 Akim> cat >configure.in <<EOF
 Akim> AC_INIT
 Akim> AC_OUTPUT(sub/foo:in/sub.in)
 Akim> EOF
 Akim> mkdir in
 Akim> echo '@srcdir@' >in/sub.in       # <<<===
 Akim> autoconf2.13                     # <<<===
 Akim> mkdir _build
 Akim> cd _build
 Akim> ../configure
 Akim> cat sub/foo                      # <<<===

 Akim> => ../../sub

 > This looks correct to me.

 > [...]

 > We seems to disagree about what @srcdir@ means.  For me, it's a
 > relative path from the current build directory to its twin
 > source directory.  Especially, this become `.' when in non-VPATH
 > builds.  The value of this variable is global to a directory,
 > and independent on how files are constructed.  This rules out
 > option 3.

I understand your point, but, by sticking to the letter of the rule,
it somewhat results in a something that has no sense at all, while
(3), although tweaking a bit the rule, is faithful to its spirit IMHO.
But that's already what you said:

 > When the source directory corresponding to the current build
 > directory does not exist, there is a problem.  (The converse
 > cannot happen, because config.status always creates missing
 > build directories.)  Admittedly the @srcdir@ variable is of
 > little value when the directory does not exists.  Even though,
 > it's still possible to define @srcdir@ as relative path from the
 > current build directory to its (possibly nonexistent) twin
 > source directory.  Autoconf does this very well presently.

The question is more like "should srcdir and abs_srcdir be
per-directory values, or per-file values".  You seem to say
per-directory: two files in the same (build-)directory have the same
src-dir.  (3) says something else.

Your option is more like "stick to the common case even when it makes
little sense", while (3) is more like "make it useful".  But it is
true anyway that the usefulness of (3) is subject to debate, since
nobody ever asked for it...

 > My complaint is about @abs_srcdir@, not @address@hidden  While
 > @srcdir@ can be computed without assuming the existence of the
 > source directory, @abs_srcdir@ cannot, because this involves a
 > cd into this directory (and creating a directory into the source
 > tree for the sake of this cd is not an option).

 > I can see only two options to define @abs_srcdir@ when the
 > source directory does not exist:

 >  1. define @abs_srcdir@ as junk
 >  2. compute @abs_srcdir@ without using cd

 > I've suggested option 1 in my previous mail because that seems
 > the easier to implement, and I can't see why one would want to
 > use this variable when the source directory does not exist.

So why define it at all?

 > Not AC_SUBSTing @abs_srcdir@ in this case does not seem very
 > sensible, because it will be impossible for tools which trace
 > AC_SUBST to know which AC_SUBSTs are substituted and which are
 > not.  (However if what you meant was to never AC_SUBST
 > @abs_srcdir@, then I'm all for it.  IMHO all the abs_
 > substitutions are evil.)

Well, by "AC_SUSBT" I was referring to the @-substitution, but not the
actual AC_SUBST: these magic values (srcdir, buliddir, etc.)  that
change across directories require another mechanism that AC_SUBST.
You won't see them in AC_SUBST traces.


I'm not sure which I like most currently.  As Paul, I was in favor of
(3), but now, I'm not so sure :(