* Eric Blake wrote on Tue, Apr 07, 2009 at 04:41:58AM CEST:
> 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.
Yes.
> 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.
Doesn't the AC_CONFIG_COMMANDS_PRE deal with this issue?
> If AM_INIT_AUTOMAKE came first, the query whether
> EXEEXT will fail unless you delay the query until an m4_wrap cleanup
> action.
That's not what my testing showed.
> 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.
Yes, I agree.
In other occasions, it is often clear which macro introduces a variable.
For example, here it's _AC_COMPILER_EXEEXT, but that one is define'd
only, not defun'ed, so we cannot easily tuck an AC_PROVIDE_IFELSE onto
its rear. And I would like to not add this AM_CONDITIONAL code after
all of the AC_PROG_{CC,...} macros.
> > -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?
No, just for looks. I'll add a 'dnl'.
> > + [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], [],
Was the separator always a space, or did some versions use newlines,
too?
> > + [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl
> > +])dnl
> > ])
>
> Beyond that, it looks like a reasonable approach.
Thanks!
Cheers,
Ralf
