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
