[Top][All Lists]

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


From: Ralf Corsepius
Date: Tue, 23 Jan 2001 19:29:42 +0100

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 @address@hidden
Though it is not officially documented, it is widely used, and
semi-documented (cf.
[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.


Separate build-dir:

In-sourcetree configuration:

> 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
> ]])
> foo/Makefile])

=> 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.
> |, 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
> 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

> So finally, I personally consider that the only bug CVS Autoconf
> really presents is that srcdir is corrupted after AC_CONFIG_*.

To summarize: There are several issues hidden:
* The CONFIG_FILES section trashes variables a user explicitly sets
* srcdir given random contents in AC_CONFIG_COMMANDS
* srcdir silently not behaving as in autoconf-2.13. [
even destinguishes between srcdir="." and srcdir=`pwd`.]

> And since srcdir == top_srcdir, there is no point in
> documenting/implementing top_srcdir. 

> So I think the case is closed.  ?
No, I disagree. (Check out and see how it is applied
with automake in newlib.)


Ralf Corsepius 
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:address@hidden           FAX: +49/731/501-999

reply via email to

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