Re: may Automake rely on _AC_SUBST_VARS?

[Ralf Wildenhues]

* 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