bug#8718: error when using nested conditionals

tags 8718 + wontfix close 8718 thanks Reference: Hello Ralf, Bruno. On Tuesday 21 June 2011, Ralf Wildenhues wrote: > * Bruno Haible wrote on Fri, Jun 17, 2011 at 12:21:38PM CEST: > > Ralf Wildenhues wrote: > > > > There's no point in being _t

bug#8718: error when using nested conditionals

Hello Ralf, Bruno. On Tuesday 21 June 2011, Ralf Wildenhues wrote: > * Bruno Haible wrote on Fri, Jun 17, 2011 at 12:21:38PM CEST: > > Ralf Wildenhues wrote: > > > > There's no point in being _that_ safe that you check unused expressions > > > > for validity. C compilers don't do it either: When I

bug#8718: error when using nested conditionals

* Bruno Haible wrote on Fri, Jun 17, 2011 at 12:21:38PM CEST: > Ralf Wildenhues wrote: > > > 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 ,$$?! > > >

bug#8718: error when using nested conditionals

Ralf Wildenhues wrote: > Please note that this does have a small change in semantics, namely if > there is code using AM_COND_IF Thanks for the heads-up; I'll change the code to handle that as well. > > There's no point in being _that_ safe that you check unused expressions > > for validity. C co

bug#8718: error when using nested conditionals

Hi Ralf, > More danger ahead: > > if $foo; then result=ok; else result=bad; fi > AM_CONDITIONAL([COND1], [test $result = ok]) > if $bar; then result=ok; else result=bad; fi > AM_CONDITIONAL([COND2], [test $result = ok]) > > I've seen such code in third party projects, it will break if you delay

bug#8718: error when using nested conditionals

* Ralf Wildenhues wrote on Fri, Jun 17, 2011 at 07:47:35AM CEST: > * 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([...])]) > >

bug#8718: error when using nested conditionals

* 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

bug#8718: error when using nested conditionals

Hello Ralf, > > === 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]) > > Instea

bug#8718: error when using nested conditionals

Hello, and sorry for the delay, * Bruno Haible wrote on Fri, Jun 10, 2011 at 01:29:57AM CEST: > > 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

bug#8718: error when using nested conditionals

On Friday 10 June 2011, Bruno Haible wrote: > 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_F

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 branc

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 cod

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

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 ma

bug#8718: error when using nested conditionals

On Fri, Jun 10, 2011 at 6:19 PM, Stefano Lattarini wrote: > 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: > > -snip- > > will cause the generated configure to check tha

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_CON

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.

bug#8718: error when using nested conditionals

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 write code like this:

bug#8718: error when using nested conditionals

On Monday 23 May 2011, Bruno Haible wrote: > Hi, > Hello Bruno, sorry for the delay. > When a Makefile.am has nested conditionals, then when an inner conditional > is not defined _and_ not needed (because it's in an unused part of the > Makefile.am), then 'configure' nevertheless emits a fatal err

bug#8718: error when using nested conditionals

Hi, When a Makefile.am has nested conditionals, then when an inner conditional is not defined _and_ not needed (because it's in an unused part of the Makefile.am), then 'configure' nevertheless emits a fatal error. This causes major problems for the new 'conditional-dependencies' mode of gnulib-t