Re: AC_OUTPUT_COMMANDS

[Ralf Corsepius]

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. 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:address@hidden           FAX: +49/731/501-999  
http://www.faw.uni-ulm.de