autoconf-patches
[Top][All Lists]
Advanced

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

Re: may Automake rely on _AC_SUBST_VARS?


From: Eric Blake
Subject: Re: may Automake rely on _AC_SUBST_VARS?
Date: Mon, 06 Apr 2009 20:41:58 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[adding automake-patches]

According to Ralf Wildenhues on 4/6/2009 2:48 PM:
> This variable is undocumented, but has been used much before 2.62
> (which is the Autoconf version current Automake requires).  Would
> it be ok to rely on this undocumented variable, and push the patch
> below to Autoconf?

That is, you want to continue to keep it undocumented in the manual, but
make us think twice about changing it prior to a release.  For now, the
raw use of the variable is probably safe enough.  Ultimately, if other
people start wanting to get at the same information, we can add a public
wrapper along the lines of:

# AC_SUBST_VARS_QUERY([VAR], [IF-USED], [IF-UNUSED])
# --------------------------------------------------
# If VAR has previously been the subject of AC_SUBST, expand IF-USED,
# else IF-UNUSED.

But, I don't want a macro like this just yet.  In particular, consider the
fact that AM_INIT_AUTOMAKE is currently allowed to occur either before or
after AC_PROG_CC.  If AM_INIT_AUTOMAKE came first, the query whether
EXEEXT will fail unless you delay the query until an m4_wrap cleanup
action.  It is this ordering dependency that makes documenting the use of
such a wrapper difficult, and why I don't mind leaving automake to use the
undocumented internals, once we have the nice comment in place to remind
us of this decision.

> -AC_CONFIG_COMMANDS_PRE([AM_CONDITIONAL([am__EXEEXT], [test -n 
> "$EXEEXT"])])dnl
> +AC_CONFIG_COMMANDS_PRE([
> +dnl In Autoconf 2.62 and 2.63, _AC_SUBST_VARS is a simple string,
> +dnl starting with 2.64 it will be a set with efficient access.
> +  m4_ifdef([m4_set_contains],

This adds some whitespace after the leading '[' that was not present in
the previous version and is not stripped by m4.  Is that intentional?

> +    [m4_set_contains([_AC_SUBST_VARS], [EXEEXT],
> +       [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])],
> +    [m4_if([m4_index([_AC_SUBST_VARS], [EXEEXT])], [-1], [],

Oops - you missed m4_defn, and overquoted m4_index; your m4_if will always
take the fourth parameter as written.  Also, to avoid problems with
variables like MY_EXEEXT, I would write this line as:

[m4_if(m4_index([ ]m4_defn([_AC_SUBST_VARS])[ ], [ EXEEXT ]), [-1], [],

> +           [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl
> +])dnl
>  ])

Beyond that, it looks like a reasonable approach.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknavXUACgkQ84KuGfSFAYCcPgCfUWqf9GKQmW4lxHVP9C9Iaz7U
464AnjSo4jNj7LOYB7JeWhV3aw0g4E7w
=GdpU
-----END PGP SIGNATURE-----




reply via email to

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