autoconf
[Top][All Lists]
Advanced

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

Re: AC_OUTPUT_COMMANDS


From: Akim Demaille
Subject: Re: AC_OUTPUT_COMMANDS
Date: 23 Jan 2001 17:27:02 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake)

| 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

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.


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


| AFAIS, apparent cause is autoconf-2.[4]* placing INIT-COMMANDS
| before the CONFIG_FILES section in config.status, and the
| CONFIG_FILES section working on variables which had been constant
| with autoconf-2.13.

I exchanged them on purpose, given that since you can now attach
actions to AC_CONFIG_FILES etc. which are performed *after* the
instantiation, it is more powerful to run AC_CONFIG_COMMANDS before.


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?

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.
Otherwise @top_srcdir@ and $top_srcdir would be different.

So finally, I personally consider that the only bug CVS Autoconf
really presents is that srcdir is corrupted after AC_CONFIG_*.  Which
I don't observe by the way:

/tmp % cat configure.in                                          nostromo 17:21
AC_INIT
echo "@srcdir@">file.in
test -d foo || mkdir foo
echo "@srcdir@">foo/file.in
echo $srcdir
AC_OUTPUT(file foo/file)
echo $srcdir
cat file
cat foo/file
/tmp % mkdir build                                               nostromo 17:22


This is 2.13
/tmp % /usr/bin/autoconf                                         nostromo 17:22
/tmp % cd build                                                  nostromo 17:22
/tmp/build % ../configure                                        nostromo 17:22
creating cache ./config.cache
..
updating cache ./config.cache
creating ./config.status
creating file
creating foo/file
..
..
../../foo


This is CVS
/tmp/build % ..                                                  nostromo 17:22
/tmp % ace                                                       nostromo 17:22
/tmp % cd build                                                  nostromo 17:22
/tmp/build % ../configure                                        nostromo 17:22
..
configure: creating ./config.status
config.status: creating file
config.status: creating foo/file
..
..
../../foo



And since srcdir == top_srcdir, there is no point in
documenting/implementing top_srcdir.  So I think the case is closed.  ?



reply via email to

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