bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8718: error when using nested conditionals


From: Stefano Lattarini
Subject: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 10:19:43 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]