bug#8718: error when using nested conditionals
On Friday 10 June 2011, Bruno Haible wrote:
Hi Stefano,
Cannot you simply initialize the
automake conditionals you might need and that you know might be called
conditionally to (possibly dummy) defaults in gl_INIT or gl_EARLY or
something like that?
No, I cannot do that. The gnulib users
You mean the authors of gnulib modules here, right?
write code like this:
=== foo.m4
AC_DEFUN([gl_FOO],
[
if test 7 = 7; then
use_variant_a=true
else
use_variant_a=false
fi
AM_CONDITIONAL([USE_VARIANT_A], [$use_variant_a])
])
=== foo.mk
if USE_VARIANT_A
libgnu_a_SOURCES += foo_a.c
else
libgnu_a_SOURCES += foo_b.c
endif
===
on which I have no influence, and from which I cannot extract/collect the
USE_VARIANT_A identifier.
OK, I see. Your use case is very clear now, thank you.
autoconf
knows nothing about the Makefile.am files, and the current autotools
layerization does not allow autoconf to use any sort of callback to
automake to get such information
But when autoconf's generated configure file produces the error
configure: error: conditional USE_VARIANT_A was never defined.
it must have gotten the info please check that USE_VARIANT_A is defined.
From Automake, when it scanned the Makefile.am.
Nope, it gets the information from the fact each AM_CONDITIONAL invocation
does this:
AC_CONFIG_COMMANDS_PRE(
[if test -z ${$1_TRUE} test -z ${$1_FALSE}; then
AC_MSG_ERROR([[conditional $1 was never defined.
Usually this means the macro was only invoked conditionally.]])
fi])])
Automake never passes any information to autoconf.
What I'm asking for is that
- Automake's scanning of Makefile.am keeps track of which conditionals
are enabled at each line.
- Automake passes to Autoconf the info please check that either USE_FOO
has the value 'false' or USE_VARIANT_A is defined.
But there is no natural way for automake to pass that information to
autoconf or aclocal, unless we set out to make the autotools layering
and interdependencies even more complex than they are now. I'm not
sure this use case warrants that, since we can found easier (even if
suboptimal) workarounds.
it could be easily done with
a new m4 macro, say 'AM_IGNORE_UNDEFINED_CONDITIONALS'.
Or with an Automake option that I add to the Makefile.am.
Oh no, this would imply that automake can communicate stuff to autoconf;
and in this case we could use your more correct fix proposed above.
I don't mind which way.
Here is my idea: 'AM_IGNORE_UNDEFINED_CONDITIONALS' can accept two
arguments, yes and no (defaulting to yes if no argument is given).
The idea is that an usage like:
AM_CONDITIONAL([FOO], [:])
AM_IGNORE_UNDEFINED_CONDITIONALS([yes])
if test -n $user_flag; then
AM_CONDITIONAL([BAR], [test $user_flag = yes])
fi
AM_IGNORE_UNDEFINED_CONDITIONALS([no])
if test 1 = 1; then
AM_CONDITIONAL([BAZ], [:])
fi
will cause the generated configure to check that the FOO and BAZ
conditionals are defined, but not to check that the BAR conditional
is defined. WDYT?
Regards,
Stefano
bug#8718: error when using nested conditionals
Hi Stefano, 'AM_IGNORE_UNDEFINED_CONDITIONALS' can accept two arguments, yes and no (defaulting to yes if no argument is given). The idea is that an usage like: AM_CONDITIONAL([FOO], [:]) AM_IGNORE_UNDEFINED_CONDITIONALS([yes]) if test -n $user_flag; then AM_CONDITIONAL([BAR], [test $user_flag = yes]) fi AM_IGNORE_UNDEFINED_CONDITIONALS([no]) if test 1 = 1; then AM_CONDITIONAL([BAZ], [:]) fi will cause the generated configure to check that the FOO and BAZ conditionals are defined, but not to check that the BAR conditional is defined. This would fit gnulib's use-case. Thank you. Actually this pair of AM_IGNORE_UNDEFINED_CONDITIONALS invocations looks like something that should be nestable: AM_IGNORE_UNDEFINED_CONDITIONALS([yes]) if test $enable_foo; then AM_CONDITIONAL([FOO], [:]) fi AM_IGNORE_UNDEFINED_CONDITIONALS([yes]) if test -n $user_flag; then AM_CONDITIONAL([BAR], [test $user_flag = yes]) fi AM_IGNORE_UNDEFINED_CONDITIONALS([no]) if test 0 = 1; then AM_CONDITIONAL([BAZ], [:]) fi AM_IGNORE_UNDEFINED_CONDITIONALS([no]) should cause the generated configure to not check about FOO, BAR, BAZ. Since the usual way to implement nestable behaviour in Autoconf is m4_pushdef / m4_popdef, maybe it is sufficient to document a single m4_define'd macro, say, AM_CHECK_CONDITIONALS_DEFINED, so that the snippet above can be written as: m4_pushdef([AM_CHECK_CONDITIONALS_DEFINED], []) if test $enable_foo; then AM_CONDITIONAL([FOO], [:]) fi m4_pushdef([AM_CHECK_CONDITIONALS_DEFINED], []) if test -n $user_flag; then AM_CONDITIONAL([BAR], [test $user_flag = yes]) fi m4_popdef([AM_CHECK_CONDITIONALS_DEFINED]) if test 0 = 1; then AM_CONDITIONAL([BAZ], [:]) fi m4_popdef([AM_CHECK_CONDITIONALS_DEFINED]) Bruno -- In memoriam Lamana Ould Bou http://fr.wikipedia.org/wiki/Lamana_Ould_Bou
bug#8718: error when using nested conditionals
Jack Kelly wrote: AM_IGNORE_UNDEFINED_CONDITIONALS(REGEX) ignores undefined-conditional errors for conditions that match REGEX. With this proposal, gnulib would have to turn off all undefined-conditional errors, that is, use a regex of [.*]. That's because as exemplified in the previous mail, foo.m4 and foo.mk are created by package authors (outside the gnulib maintainers team) whom we don't want to bother with the need to find a regex. Whereas with Stefano's proposal, the disabled error-checking can be limited to the m4 code portions that have been processed through gnulib-tool, leaving it enabled for the package's configure.ac. Bruno -- In memoriam Lamana Ould Bou http://fr.wikipedia.org/wiki/Lamana_Ould_Bou
bug#8718: error when using nested conditionals
On Fri, 10 Jun 2011, Stefano Lattarini wrote:
Nope, it gets the information from the fact each AM_CONDITIONAL invocation
does this:
AC_CONFIG_COMMANDS_PRE(
[if test -z ${$1_TRUE} test -z ${$1_FALSE}; then
AC_MSG_ERROR([[conditional $1 was never defined.
Usually this means the macro was only invoked conditionally.]])
fi])])
Hi Stefano, Bruno,
how about the following alternative (for all conditionals, or just for some
of them, e.g., those under the regime of AM_IGNORE_UNDEFINED_CONDITIONALS):
Replace the AC_MSG_ERROR() above by a warning and set both $1_TRUE and
$1_FALSE to something that, when not hidden in a false branch of the
Makefile, (1) triggers a make syntax error, and (2) contains sufficient info
to deduce the cause for that error.
That way there is a warning from configure (often overlooked and/or
ignored), but an error from make only if that conditional is actually
needed.
Regards
Peter
bug#8718: error when using nested conditionals
Since the usual way to implement nestable behaviour in Autoconf is m4_pushdef / m4_popdef Another idea would to be m4_pushdef AM_CONDITIONAL itself. If you add a third parameter to AM_CONDITIONAL, denoting the conditions in which the conditional needs to be defined, then gnulib could emit code like this: m4_define([AM_CONDITIONAL_ORIG], m4_defn([AM_CONDITIONAL])) AC_DEFUN([gl_LENIENT_CONDITIONAL], [AM_CONDITIONAL_ORIG([$1],[$2],[USE_FOO])]) m4_pushdef([AM_CONDITIONAL], [gl_LENIENT_CONDITIONAL]) if test $enable_foo; then AM_CONDITIONAL([FOO], [:]) fi m4_pushdef([AM_CONDITIONAL], [gl_LENIENT_CONDITIONAL]) if test -n $user_flag; then AM_CONDITIONAL([BAR], [test $user_flag = yes]) fi m4_popdef([AM_CONDITIONAL]) if test 0 = 1; then AM_CONDITIONAL([BAZ], [:]) fi m4_popdef([AM_CONDITIONAL]) But it certainly gets hairy... Bruno -- In memoriam Lamana Ould Bou http://fr.wikipedia.org/wiki/Lamana_Ould_Bou
bug#8718: error when using nested conditionals
Peter, how about the following alternative (for all conditionals, or just for some of them, e.g., those under the regime of AM_IGNORE_UNDEFINED_CONDITIONALS): Replace the AC_MSG_ERROR() above by a warning and set both $1_TRUE and $1_FALSE to something that, when not hidden in a false branch of the Makefile, (1) triggers a make syntax error, and (2) contains sufficient info to deduce the cause for that error. Sounds good. But gnulib would also need a way to disable the warning, because otherwise the maintainers of packages that use gnulib come back to me and ask how they can get rid of the warning. Bruno -- In memoriam Lamana Ould Bou http://fr.wikipedia.org/wiki/Lamana_Ould_Bou
