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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8718 in the body.
You can then email your comments to 8718 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-automake <at> gnu.org
Subject: error when using nested conditionals
Date: Mon, 23 May 2011 00:30:41 +0200

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

How to reproduce:

In an empty directory, create these files and then run the following commands.
================================ configure.ac =================================
AC_INIT([dummy], [0])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
AC_PROG_RANLIB
if test 4 = 5; then
  use_foo=true
  gl_FOO
else
  use_foo=false
fi
AM_CONDITIONAL([USE_FOO], [$use_foo])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
=================================== 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])
])
================================= Makefile.am =================================
ACLOCAL_AMFLAGS = -I .
noinst_LIBRARIES = libgnu.a
libgnu_a_SOURCES = bar.c
if USE_FOO
include foo.mk
else
libgnu_a_SOURCES += gazonk.c
endif
=================================== foo.mk ====================================
if USE_VARIANT_A
libgnu_a_SOURCES += foo_a.c
else
libgnu_a_SOURCES += foo_b.c
endif
===============================================================================
$ touch bar.c foo_a.c foo_b.c gazonk.c
$ aclocal -I .
$ automake -a -c
$ autoconf
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
configure: error: conditional "USE_VARIANT_A" was never defined.
Usually this means the macro was only invoked conditionally.

The value of USE_VARIANT_A is irrelevant, because it occurs in the "if USE_FOO"
part and USE_FOO evaluates to false.

I don't see how this error could be worked around in gnulib, because
  1) it is a fatal error.
  2) What I would need is to extract all AM_CONDITIONALs from foo.m4
     and execute them with 'false' or 'true' values (doesn't matter which)
     before executing the code

       if test 4 = 5; then
         use_foo=true
         gl_FOO
       else
         use_foo=false
       fi

     But because the files { foo.m4, foo.mk, foo_a.c, foo_b.c } should be
     considered as a unit, and there's no way to execute _just_ the
     AM_CONDITIONALs inside gl_FOO and not the other statements, I'm
     blocked.

I do agree that it can be a useful behaviour of Automake to check that
all conditional have values, not only those that are really used. But it
should better a warning, rather than an error, and there should be a way
to turn it off.

Bruno
-- 
In memoriam Richard Friedmann <http://de.wikipedia.org/wiki/Richard_Friedmann>

Message #8 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 8718 <at> debbugs.gnu.org
Subject: Re: bug#8718: error when using nested conditionals
Date: Thu, 9 Jun 2011 21:17:48 +0200

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 error.
>
Ah, but the problem is, autoconf *and* the Automake-provided m4 macros have
no way to know that the conditional is not needed; this is because 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 (and trying to implement such a "callback"
could open a really, really nasty can of worms IMHO).

> This causes major problems for the new 'conditional-dependencies' mode of
> gnulib-tool.
> 
> How to reproduce:
> 
> In an empty directory, create these files and then run the following commands.
> ================================ configure.ac =================================
> AC_INIT([dummy], [0])
> AM_INIT_AUTOMAKE([foreign])
> AC_PROG_CC
> AC_PROG_RANLIB
> if test 4 = 5; then
>   use_foo=true
>   gl_FOO
> else
>   use_foo=false
> fi
> AM_CONDITIONAL([USE_FOO], [$use_foo])
> AC_CONFIG_FILES([Makefile])
> AC_OUTPUT
> =================================== 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])
> ])
> ================================= Makefile.am =================================
> ACLOCAL_AMFLAGS = -I .
> noinst_LIBRARIES = libgnu.a
> libgnu_a_SOURCES = bar.c
> if USE_FOO
> include foo.mk
> else
> libgnu_a_SOURCES += gazonk.c
> endif
> =================================== foo.mk ====================================
> if USE_VARIANT_A
> libgnu_a_SOURCES += foo_a.c
> else
> libgnu_a_SOURCES += foo_b.c
> endif
> ===============================================================================
> $ touch bar.c foo_a.c foo_b.c gazonk.c
> $ aclocal -I .
> $ automake -a -c
> $ autoconf
> $ ./configure
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of gcc... gcc3
> checking for ranlib... ranlib
> configure: error: conditional "USE_VARIANT_A" was never defined.
> Usually this means the macro was only invoked conditionally.
> 
> The value of USE_VARIANT_A is irrelevant, because it occurs in the "if USE_FOO"
> part and USE_FOO evaluates to false.
> 
> I don't see how this error could be worked around in gnulib, because
>   1) it is a fatal error.
>   2) What I would need is to extract all AM_CONDITIONALs from foo.m4
>      and execute them with 'false' or 'true' values (doesn't matter which)
>      before executing the code
> 
>        if test 4 = 5; then
>          use_foo=true
>          gl_FOO
>        else
>          use_foo=false
>        fi
> 
>      But because the files { foo.m4, foo.mk, foo_a.c, foo_b.c } should be
>      considered as a unit, and there's no way to execute _just_ the
>      AM_CONDITIONALs inside gl_FOO and not the other statements, I'm
>      blocked.
>
I'm not sure I'm following you here.  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?  Sorry if this is a stupid question, but I lack any
real knowledge about this 'conditional-dependencies' mode of gnulib-tool
you're referring to, so I'm mostly guessing here; links or documentation
that can remedy to my ignorance are welcome ;-)

> I do agree that it can be a useful behaviour of Automake to check that
> all conditional have values, not only those that are really used. But it
> should better a warning, rather than an error,
>
I disagree with this, because a configure-time warning could easily go
undetected (much more than an autoconf-time or automake-time warning,
anyway), and thus hide potential bugs.

> and there should be a way to turn it off.
>
This is a sensible and justified request in case we fail to find any easy
workaround to your current predicament.  And it could be easily done with
a new m4 macro, say 'AM_IGNORE_UNDEFINED_CONDITIONALS'.  But I'd rather
try, if possible, to find a solution that works with current Automake too,
and avoid the introduction of yet another macro or yet another option.

Regards,
  Stefano

Message #11 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 8718 <at> debbugs.gnu.org
Subject: Re: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 01:29:57 +0200

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:

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

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

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

> 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. I don't mind which
way.

Bruno
-- 
In memoriam Johanna Kirchner <http://en.wikipedia.org/wiki/Johanna_Kirchner>

Message #14 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 8718 <at> debbugs.gnu.org
Subject: Re: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 10:19:43 +0200

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

Message #17 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 8718 <at> debbugs.gnu.org
Subject: Re: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 11:24:20 +0200

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>

Message #20 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 8718 <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 19:32:38 +1000

On Fri, Jun 10, 2011 at 6:19 PM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> 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 that the FOO and BAZ
> conditionals are defined, but not to check that the BAR conditional
> is defined.  WDYT?

I have a counter-proposal.

AM_IGNORE_UNDEFINED_CONDITIONALS(REGEX) ignores
"undefined-conditional" errors for conditions that match REGEX. To
allow multiple packages to register their conditionals, make it append
REGEX to a list of regexen to check. If a conditional matches any of
these regexen, it is not an error.

AM_ENFORCE_UNDEFINED_CONDITIONALS(REGEX) does the opposite: if a
conditional is undefined, matches one of the
AM_IGNORE_UNDEFINED_CONDITIONALS regexen, but matches one of the
AM_ENFORCE_UNDEFINED_CONDITIONALS regexen, then it is still an error.

WDYT?

-- Jack

Message #23 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Jack Kelly <jack <at> jackkelly.name>
Cc: 8718 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 11:44:57 +0200

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>

Message #26 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Peter Breitenlohner <peb <at> mppmu.mpg.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, 8718 <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>,
	owner <at> debbugs.gnu.org
Subject: Re: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 12:23:42 +0200 (CEST)

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

Message #32 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 8718 <at> debbugs.gnu.org
Subject: Re: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 12:44:46 +0200

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

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Peter Breitenlohner <peb <at> mppmu.mpg.de>
Cc: bug-automake <at> gnu.org, 8718 <at> debbugs.gnu.org,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, owner <at> debbugs.gnu.org
Subject: Re: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 12:47:56 +0200

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>

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>,
 bug-automake <at> gnu.org
Cc: Peter Breitenlohner <peb <at> mppmu.mpg.de>, 8718 <at> debbugs.gnu.org
Subject: Re: bug#8718: error when using nested conditionals
Date: Fri, 10 Jun 2011 13:45:21 +0200

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_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
> 
I like Peter proposal too, it's neat and shouldn't be difficult to implement
and document.  But maybe I like Bruno's latest proposal about adding a third
argument to AM_CONDITIONAL even more; see:
 <http://lists.gnu.org/archive/html/bug-automake/2011-06/msg00009.html>
The problem is, how would that scale on more complex situations?  That's not
quite obvious to me.  Peter's proposal seems safer in this regard.

Hmmm, I can't really decide between these two proposals offhand.  Let's wait
a couple of days to see if Ralf can chime in, OK?  Otherwise we'll try to
sort this out ourselves.

For the moment, thank you all for your ideas and contribution.

Regards,
  Stefano

Message #47 received at 8718 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#8718: error when using nested conditionals
Date: Thu, 16 Jun 2011 21:48:59 +0200

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 that?
> 
> No, I cannot do that. The gnulib users write code like this:

Of course you can do that.

> =================================== 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])

Instead of this line, you could use
  AC_CONFIG_COMMANDS_PRE([AM_CONDITIONAL([...])])

to force the AM_CONDITIONAL statement to be executed at outer shell
level, late, and unconditionally.  Untested (if it gets the order
wrong wrt. the inner AC_CONFIG_COMMANDS_PRE, ping me, there should be
another way around it).

> ])

It's rather funny that this construct has been floated around this very
thread a couple of times without the implied conclusion.

I must say I don't like any of the other suggestions in this thread too
much.  You otherwise like being safe rather than sorry too, and there is
no compelling argument to weaken automake's consistency detection here.

Cheers,
Ralf

Message #50 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: "Ralf Wildenhues" <Ralf.Wildenhues <at> gmx.de>
Cc: 8718 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#8718: error when using nested conditionals
Date: Thu, 16 Jun 2011 23:42:51 +0200

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])
> 
> 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:

================================= configure.ac =================================
AC_INIT([dummy], [0])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
AC_PROG_RANLIB

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

if test 4 = 5; then
  use_foo=true
  gl_FOO
else
  use_foo=false
fi
AM_CONDITIONAL([USE_FOO], [$use_foo])

m4_popdef([AM_CONDITIONAL])

AC_CONFIG_FILES([Makefile])
AC_OUTPUT
================================================================================

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

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

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. It is a pity if Autoconf + Automake cannot do the
same. Oh well. But at least we've got a workaround now. Thanks.

Bruno
-- 
In memoriam Imre Nagy <http://en.wikipedia.org/wiki/Imre_Nagy>

Message #53 received at 8718 <at> debbugs.gnu.org (full text, mbox):

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

Message #56 received at 8718 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#8718: error when using nested conditionals
Date: Fri, 17 Jun 2011 08:59:30 +0200

* 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([...])])
> > 
> > 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.

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
the AM_CONDITIONAL evaluation.  Haven't checked whether gnulib uses
globally valid tests throughout.

Cheers,
Ralf

Message #59 received at 8718 <at> debbugs.gnu.org (full text, mbox):

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

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
> the AM_CONDITIONAL evaluation.

Thanks for the heads-up. The code I posted does not delay the evaluation of
the condition; it only delays the invocation of AM_CONDITIONAL. So it will
work fine in this situation.

Bruno
-- 
In memoriam The victims of the East German uprising <http://en.wikipedia.org/wiki/Uprising_of_1953_in_East_Germany>

Message #62 received at 8718 <at> debbugs.gnu.org (full text, mbox):

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

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

No, the generated Makefile will be right because all uses of
<COND>_TRUE and <COND>_FALSE will be inside Makefile comments, where the
comment marker "#" comes out of the expansion of the outer conditional.

> 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

I don't see a problem with negation. Here's a test case:

================================ configure.ac ================================
AC_INIT([dummy], [0])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
AC_PROG_RANLIB
if test 4 = 5; then
  use_foo=true
  AM_CONDITIONAL([USE_VARIANT_A], [false])
else
  use_foo=false
  AM_CONDITIONAL([USE_VARIANT_B], [false])
fi
AM_CONDITIONAL([USE_FOO], [$use_foo])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
================================ Makefile.am =================================
if USE_FOO
if USE_VARIANT_A
all : test1.o
endif
endif

if USE_FOO
if !USE_VARIANT_A
all : test2.o
endif
endif

if !USE_FOO
if USE_VARIANT_B
all : test3.o
endif
endif

if !USE_FOO
if !USE_VARIANT_B
all : test4.o
endif
endif
==============================================================================

Then the generated Makefile.in contains these lines:

  @USE_FOO_TRUE@@USE_VARIANT_A_TRUE <at> all : test1.o

  @USE_FOO_TRUE@@USE_VARIANT_A_FALSE <at> all : test2.o

  @USE_FOO_FALSE@@USE_VARIANT_B_TRUE <at> all : test3.o

  @USE_FOO_FALSE@@USE_VARIANT_B_FALSE <at> all : test4.o

This means:
  - If USE_FOO evaluates to false, all uses of @USE_VARIANT_A_TRUE@
    and @USE_VARIANT_A_FALSE@ are preceded by @USE_FOO_TRUE@ which is
    replaced by "#". Thus their values don't matter.
  - Similarly, if USE_FOO evaluates to true, all uses of @USE_VARIANT_B_TRUE@
    and @USE_VARIANT_B_FALSE@ are preceded by @USE_FOO_FALSE@ which is
    replaced by "#". Thus their values don't matter.

And the generated Makefile has:

  #all : test1.o

  #all : test2.o

  #all : test3.o

  all : test4.o

Which is working perfectly fine. And even if it were

  #@USE_VARIANT_A_TRUE <at> all : test1.o

  #@USE_VARIANT_A_FALSE <at> all : test2.o

  #all : test3.o

  all : test4.o

it would be working fine.

So, there is no problem with the generated Makefiles if the checks would
be weakened check only the definedness of conditionals that are actually
used in the Makefiles.

> the safety net around them definitely is not too strict.

I disagree. It is too strict without necessity.

Bruno
-- 
In memoriam The victims of the East German uprising <http://en.wikipedia.org/wiki/Uprising_of_1953_in_East_Germany>

Message #65 received at 8718 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#8718: error when using nested conditionals
Date: Tue, 21 Jun 2011 22:24:42 +0200

* 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 ((((,$$?!
> > >   #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.
> 
> No, the generated Makefile will be right because all uses of
> <COND>_TRUE and <COND>_FALSE will be inside Makefile comments, where the
> comment marker "#" comes out of the expansion of the outer conditional.

Stefano already explained this: there is no way that automake (which can
see your Makefile.am) can analyze your configure.ac shell code semantics
to infer that the situation is in fact safe.

And I don't think gnulib-tool can somehow infer that AM_CONDITIONAL
invocations from third-party macros other than gnulib, or from the
configure.ac in question, do not rely on where the AM_CONDITIONAL is
expanded.

> So, there is no problem with the generated Makefiles if the checks would
> be weakened check only the definedness of conditionals that are actually
> used in the Makefiles.

gnulib does not control all AM_CONDITIONALs in a configure.

Cheers,
Ralf

Message #68 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: "Ralf Wildenhues" <Ralf.Wildenhues <at> gmx.de>
Cc: 8718 <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#8718: error when using nested conditionals
Date: Tue, 26 Jul 2011 15:09:45 +0200

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 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.
> > 
> > No, the generated Makefile will be right because all uses of
> > <COND>_TRUE and <COND>_FALSE will be inside Makefile comments, where the
> > comment marker "#" comes out of the expansion of the outer conditional.
> 
> Stefano already explained this: there is no way that automake (which can
> see your Makefile.am) can analyze your configure.ac shell code semantics
> to infer that the situation is in fact safe.
> 
> And I don't think gnulib-tool can somehow infer that AM_CONDITIONAL
> invocations from third-party macros other than gnulib, or from the
> configure.ac in question, do not rely on where the AM_CONDITIONAL is
> expanded.
> 
> > So, there is no problem with the generated Makefiles if the checks would
> > be weakened check only the definedness of conditionals that are actually
> > used in the Makefiles.
> 
> gnulib does not control all AM_CONDITIONALs in a configure.
> 
> Cheers,
> Ralf
> 
In the end, should we close this bug as "wontfix" then?

Regards,
  Stefano

Message #71 received at 8718 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: "Ralf Wildenhues" <Ralf.Wildenhues <at> gmx.de>
Cc: 8718 <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#8718: error when using nested conditionals
Date: Thu, 1 Sep 2011 15:14:08 +0200

[Message part 1 (text/plain, inline)]

tags 8718 + wontfix
close 8718
thanks

Reference:
 <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8718>

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 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.
> > 
> > No, the generated Makefile will be right because all uses of
> > <COND>_TRUE and <COND>_FALSE will be inside Makefile comments, where the
> > comment marker "#" comes out of the expansion of the outer conditional.
> 
> Stefano already explained this: there is no way that automake (which can
> see your Makefile.am) can analyze your configure.ac shell code semantics
> to infer that the situation is in fact safe.
> 
> And I don't think gnulib-tool can somehow infer that AM_CONDITIONAL
> invocations from third-party macros other than gnulib, or from the
> configure.ac in question, do not rely on where the AM_CONDITIONAL is
> expanded.
> 
> > So, there is no problem with the generated Makefiles if the checks would
> > be weakened check only the definedness of conditionals that are actually
> > used in the Makefiles.
> 
> gnulib does not control all AM_CONDITIONALs in a configure.
> 
> Cheers,
> Ralf
> 
Given the lack of consensus of how and whether the limitations analyzed
in this reported should be lifted, and the fact that two months have passed
without further discussions, I've closed this bug marking it as "wontfix";
feel free to re-open it if the situation changes.

Regards,
  Stefano

[Message part 2 (text/html, inline)]

Previous Next

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