Akim Demaille wrote:
>
> | Hi,
>
> Hi Ralf,
>
> | srcdir and top_srcdir get corrupted with cvs-autoconf, when using
> | them in AC_OUTPUT_COMMANDS and AC_CONFIG_COMMANDS in packages with
> | subdirectories.
>
> Well, the issue you raise is interesting, but I'd like to first state
> that you are referring to a totally undocumented ``feature'' of
> Autoconf: what is documented and implemented are srcdir and top_srcdir
> as output variables, i.e., @srcdir@ and @top_srcdir@.
>
Though it is not officially documented, it is widely used, and
semi-documented (cf. config-ml.in).
[Retreating argumentation on formalism always is the weakest of all
possibile answers :)]
> So for instance, the following sentence...
>
> | Using AC_CONFIG_COMMANDS instead of AC_OUTPUT_COMMANDS results into
> | the same broken behavior.
>
> does not hold. GIGO.
>
Counter-proof:
Separate build-dir:
srcdir=../../commands/foo
top_srcdir=../../commands
In-sourcetree configuration:
srcdir=.
top_srcdir=..
cat configure.in
> AC_INIT
> AC_CONFIG_SRCDIR([foo])
>
> AM_INIT_AUTOMAKE(foo,0,no)
>
> AC_CONFIG_COMMANDS([default-1],[[
> echo srcdir=$srcdir
> echo top_srcdir=$top_srcdir
> ]],[[srcdir=$srcdir
> top_srcdir=$top_srcdir
> ]])
>
> AC_CONFIG_FILES([Makefile
> foo/Makefile])
> AC_OUTPUT
=> Random (== BROKEN) behaviour.
> | => having changed the behavior of srcdir in autoconf-2.[45]* breaks
> | all autoconf-2.13 configure scripts which assume srcdir to point to
> | the actual top_srcdir, i.e. this breaks multilib support (cf.
> | config-ml.in, used by the gnu toolchain and many other packages).
>
> If one wants the same behavior, she'll have to compute those vars by
> herself. It's an accident that it worked before.
Then it was a good accident and the current behavior should be
regarded as a regression.
> Back to the point that remains: what should we do wrt srcdir and
> top_srcdir: keep them undefined just like before, or should we have
> configure set them at its beginning?
If you want to avoid trouble, them they the behavior should at least
be deterministic (More precisely: CONFIG-FILES must not alter
variables users explicitly set in INIT of AC_CONFIG_*).
If you want to go the way of least resistance, I would recommend to
set srcdir to the value it has had in autoconf-2.13 and set
top_srcdir (Using srcdir is a work around for wanting top_srcdir in
configure.in).
> In which case it seems to me there is only one definition which makes
> sense (to me): srcdir and top_srcdir share the very same value: they
> point to the directory holding the currently running configure.in.
Agreed.
> So finally, I personally consider that the only bug CVS Autoconf
> really presents is that srcdir is corrupted after AC_CONFIG_*.
Right.
To summarize: There are several issues hidden:
* The CONFIG_FILES section trashes variables a user explicitly sets
in AC_CONFIG_COMMANDS.
* srcdir given random contents in AC_CONFIG_COMMANDS
* srcdir silently not behaving as in autoconf-2.13. [config-ml.in
even destinguishes between srcdir="." and srcdir=`pwd`.]
> And since srcdir == top_srcdir, there is no point in
> documenting/implementing top_srcdir.
Agreed.
> So I think the case is closed. ?
No, I disagree. (Check out config-ml.in and see how it is applied
with automake in newlib.)
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:[EMAIL PROTECTED] FAX: +49/731/501-999
http://www.faw.uni-ulm.de
