bug#8718: error when using nested conditionals

[Ralf Wildenhues]

* 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