Re: may Automake rely on _AC_SUBST_VARS?

[Eric Blake]

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

According to Ralf Wildenhues on 4/6/2009 11:28 PM:
>> 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.

At which point, automake will have to use a three-phase check (ifdef
AC_SUBST_VARS_QUERY, else ifdef m4_set_contains, else flat string), or
raise its minimum autoconf requirement.

> 
>> 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?

I think that's the key - AC_CONFIG_COMMANDS_PRE already _is_ run in an
m4_wrap setting.

> 
> 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.

Why not?  A macro name can be provided without using AC_DEFUN (or
m4_defun); rather, it is AC_DEFUN that makes self-providing an automatic
event.  I see nothing that would prevent automake from doing:

m4_define([_AC_COMPILER_EXEEXT],
m4_defn([_AC_COMPILER_EXEEXT])[m4_provide([_AM_COMPILER_EXEEXT])])

m4_provide_if([_AM_COMPILER_EXEEXT],
  [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])

which means you have effectively hooked the expansion of
_AC_COMPILER_EXEEXT to set a flag that you can later query, without having
to look inside _AC_SUBST_VARS, regardless of its implementation.

>> [m4_if(m4_index([ ]m4_defn([_AC_SUBST_VARS])[ ], [ EXEEXT ]), [-1], [],
> 
> Was the separator always a space, or did some versions use newlines,
> too?

Oh.  Good point.

git show v2.62:lib/autoconf/general.m4 | grep 'append.*AC_SUBST_VARS'

shows that the separator was indeed newline, not space.  The transition to
m4_set was commit 3f1a601, where it was still newline right up to that point.

- --
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

iEYEARECAAYFAknbRaQACgkQ84KuGfSFAYAeVgCgoTA2ueyZH1MYHXTEyw95LrfU
9P0AoM7oWOkc/ijdbJ8IHkRu8tlD5lwq
=lQyN
-----END PGP SIGNATURE-----