bug#8718: error when using nested conditionals

[Stefano Lattarini]

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