* 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