Ralf Corsepius <rc040203 <at> freenet.de> writes: > >>> ... I don't want that behavior. I just want to add a feature, not to > >>> forbid a user to rebuild the files. > > The desired behavior TOTALLY makes sense (although this is an automake > > question, not an autoconf question) > > - an example is the use of color-tests > > when available, with a clean fallback to no color-tests if an older > > automake was sufficient for everything else. > > Well, this is an entirely different use-case. > > This is changing the configure's behavior at configure run-time. It is > not the running "autogen.sh" (autoreconf) case.
Huh? Vincent's question was how to make an automake-time decision about whether automake supports the silent-rules feature added in 1.11, so that on newer developer's machines, the resulting configure will support the option of that feature, but without penalizing older developer's machines and without requiring the use of AM_INIT_AUTOMAKE([1.11]). It was NOT about the configure- time question of whether the user can turn the option on or off, given a configure that was built with automake 1.11 with the silent-rules feature enabled. And even if you use automake 1.11 but choose to not enable the silent- rules feature, the resulting configure file will not support silent rules, since it depends on a corner case of make behavior that is not strictly POSIX (although it appears to be portably implemented across a wide selection of make implementations). > > And whether version checking is an appropriate means/good approach in > general at all, is a different question. m4_ifdef([AM_SILENT_RULES]) is as good as it gets - it's a feature test, which is better than a version check. As long as new automake features are always given a corresponding feature check ability, then it is possible to write configure.ac that takes advantage of the features when present without choking when used with older automake versions. -- Eric Blake _______________________________________________ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
