[Top][All Lists]
[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-----