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

Previous Next

Full log

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

Previous Next

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