GNU bug report logs - #8718
error when using nested conditionals

Previous Next

Full log

View this message in rfc822 format

From: "Ralf Wildenhues" <Ralf.Wildenhues <at> gmx.de>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 8718 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: bug#8718: error when using nested conditionals
Date: Fri, 17 Jun 2011 07:47:35 +0200

* Bruno Haible wrote on Thu, Jun 16, 2011 at 11:42:51PM CEST:
> > >   AM_CONDITIONAL([USE_VARIANT_A], [$use_variant_a])
> > 
> > Instead of this line, you could use
> >   AC_CONFIG_COMMANDS_PRE([AM_CONDITIONAL([...])])
> 
> I cannot force the gnulib users to write autoconf macros which deviate that
> much from the idioms promoted by the Automake manual. But I can override
> AM_CONDITIONAL like this:

Or you could write a gl_AM_CONDITIONAL macro (or similarly) to use
instead.

> m4_define([gl_CONDITIONAL_COUNTER], [0])
> AC_DEFUN([gl_CONDITIONAL_LATER],
> [
>   m4_define([gl_CONDITIONAL_COUNTER], m4_incr(gl_CONDITIONAL_COUNTER))
>   m4_divert_text([INIT_PREPARE], [[gl_CONDITIONAL_]gl_CONDITIONAL_COUNTER=false])
>   if [$2]; then [gl_CONDITIONAL_]gl_CONDITIONAL_COUNTER=true; else [gl_CONDITIONAL_]gl_CONDITIONAL_COUNTER=false; fi
>   AC_CONFIG_COMMANDS_PRE([AM_CONDITIONAL([$1], [[$gl_CONDITIONAL_]]]gl_CONDITIONAL_COUNTER[)])
> ])
> m4_pushdef([AM_CONDITIONAL], m4_defn([gl_CONDITIONAL_LATER]))

> This solves my problem. Thanks for the idea to use AC_CONFIG_COMMANDS_PRE.
> I will add this workaround to gnulib.

Please note that this does have a small change in semantics, namely if
there is code using AM_COND_IF: that is only valid after the
AM_CONDITIONAL has been expanded.  Now, current gnulib does not use this
(fairly new) macro, but there may be user code which does (or will) use
it.  You could poison it in the above code, if you really want to keep
overriding AM_CONDITIONAL itself.

> > You otherwise like being safe rather than sorry too, and there is
> > no compelling argument to weaken automake's consistency detection here.
> 
> This workaround also will have the effect of weakening Automake's
> consistency detection, by defining an arbitrary value (false) for each
> of the occurring conditionals. But that's inevitable as long as this
> consistency detection is too strict.

It is not too strict.  It must be this strict.  See below.

> There's no point in being _that_ safe that you check unused expressions
> for validity. C compilers don't do it either: When I compile a C program
>   #if 0
>   #if syntax error ((((,$$?!
>   #endif
>   #endif
> the second line yields no error and no warning, because the condition in
> that line is ignored.

But that's not the same thing.  AM_CONDITIONAL sets variables
<COND>_TRUE and <COND>_FALSE to either empty or '#', and at least one of
them will always be nonempty.  If you skip this initialization code, the
Makefile *will* be wrong.  You may just have been lucky to not notice
that because gnulib uses few negated conditionals
  if !FOO
  ...
  endif

or
  if FOO
  ...
  else !FOO
  ...
  endif

It may be unfortunate that the semantics of conditionals are the way
they are, but the safety net around them definitely is not too strict.

Thanks,
Ralf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.