bug#8718: error when using nested conditionals

[Stefano Lattarini]

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