Re: AC_CANONICAL_SYSTEM overwrites $@

[Ralf Wildenhues]

Hello Justin, Tollef, everyone,

* Justin Erenkrantz wrote on Fri, Jun 16, 2006 at 09:12:11PM CEST:
> 
> The point of our autoconf macro is to allow 'shortcuts', such that the 
> argument
> 
> --with-layout=Foo
> 
> rewrites prefix/libexec/etc to a specific set of values (dictated by
> our file config.layout) and then have explicit passed parameters
> override those 'layout' files.

Yes.  But I think you would agree that having your own parsing routine
that is almost a complete copy of the Autoconf one is not a common,
usual way of using Autoconf, and that it's not encouraged by the
Autoconf documentation to override the settings this way, nor do your
own argument parsing at all.  Right?  The common way to do argument
parsing with Autoconf is to use AC_ARG_WITH and AC_ARG_ENABLE.

(Note I'm not arguing the usefulness of doing so for your needs; in
fact, I understand that you do this.  But if you want to be able to rely
on Autoconf upgrades to not break your setup, you should push for
changes to Autoconf itself so it provides enough interfaces so you don't
need to do your own parsing.  It's just not natural to do so.)

> It looks like you switched the docs to recomend using AC_ARG_ENABLE,
> but I'm not sure how that would address our issue.

Paul pointed out that $@ won't stay constant througout the configure
script.  In fact, this has never been guaranteed.  Apr was just lucky
enough not to have been hit by it, and Autoconf wasn't careful enough to
document that there is no such guarantee.  (Although strictly speaking,
one may argue that since the Autoconf manual doesn't give such a
guarantee, you should not assume it.)  Paul now fixed the documentation
to state this non-guarantee more prominently (the mention of
AC_ARG_ENABLE is just a hint at the macros to use instead).

Let me repeat what I wrote in an earlier message in this bug report[1]:
The AC_CHECK_PROG macro (for example) has overwritten the positional
parameters _for years_, at least since Autoconf-2.13.  From a pure
Autoconf view, and I'm exaggerating here on purpose, relying on $@ to
remain constant over the course of the configure script is akin to
relying on "undefined behavior" in C.  Now we all know there is a world
of difference between a well-defined language such as C, and a mostly
not so well defined language such as Autoconf-on-top-of-portable-Shell.
But to speak of a major unexpected change as has been done in this bug
report seems a bit exaggerated to me.  I would even find a NEWS entry
for this change in AC_CANONICAL_SYSTEM to be more than necessary.

> We might be able to delay the AC_CANONICAL_SYSTEM invocation until
> after we process the layout options - but I seem to recall a reason
> why we delayed invoking those macros.

As as decent workaround, you could just save the positional parameters
early after AC_INIT and restore them when you need them; good code to
this end has already been posted in this bug report as well, see [2].

I see absolutely no need for Autoconf to do more for this bug.

* Tollef Fog Heen <address@hidden> wrote:
> | [...] putting some kind
> | of Debian-specific patch that saves and restores the positional
> | parameters (if indeed there's a way to do that) around
> | AC_CANONICAL_SYSTEM.
> 
> Apart from the «ewww» factor, why can't it do its work in a subshell
> and echo back the parameters to be set and those get eval-ed by
> configure?

Because configure scripts are slow enough as they are; a subshell is a
noticeable slowdown when done several times.  Because avoiding echoing
avoids the unportabilites of echo.  Doing away with modifing $@ in
general is needlessly limiting us to not be able to make efficient use
of the only array variable that is available in Shell programming.[3]

I hope this clears things up enough.

Cheers,
Ralf

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372179
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372179#msg49
[3] Eventually, Autoconf will make use of shell functions.  At that time
    you will have no chance to have $@ survive the first shell function
    invocation portably (some older shells do not restore $@ after a
    function returns; I'm not sure whether they will be of concern any
    more then or not).  So really the guarantee Paul gave in the message
    above is probably even stronger than we can give.