GNU bug report logs -
#8718
error when using nested conditionals
Previous Next
Reported by: Bruno Haible <bruno <at> clisp.org>
Date: Sun, 22 May 2011 22:31:02 UTC
Severity: normal
Tags: wontfix
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #68 received at 8718 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 13 years and 345 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.