>> Ok. So the question I'd like you to ask yourself are: >> >> * Why does it make sense to request manual declaration of 'SUFFIXES'? >> * Does it make sense to do so in Automake, too?
And another question: * Alternatively, could Automake-NG suggest converting suffix rules to pattern rules so that the extra SUFFIXES entries are not necessary anymore? Or even do that automatically in the Makefile.am -> Makefile.in conversion? >> This needs to be done for each NG-NEWS items. It could improve the >> existing users of Automake, and reduce the size of NG-NEWS. Both of >> which are good things! >> > And I've done that already where possible and reasonable. For example, > the 'silent-rules' option is now active by default, and the tags-related > rules have been reworked and improved. I might consider other similar > backports as well in the future. Cool, please do. > But in several areas, similar changes > would risk to cause serious bugs and incompatibilities which, while IMHO > acceptable in a young and still experimental software like Automake-NG, > would not be acceptable in an Automake release. Understood. It has to be done carefully. >> But CMake is not almost the same as Automake, Automake-NG is. >> Automake-NG is not Automake 2.0, but Automake 2.0 _could_ have the same >> user interface as Automake-NG. What I'm asking is, please consider a >> deprecation path in Automake for _every_ _single_ difference between it >> and Automake-NG. >> > Not doable, sorry. "Consider" != "provide". :) You can use your judgement and creativity. >> If you rewrote Automake in m4 (only partly kidding), I wouldn't have had >> these objections. But changing the name doesn't change the perception. >> > Maybe we just need good PR and "advertisment" in this. The python > developers has managed to make a 3.0 release incompatible with the 2.x > series, because they've been very clear and vocal about the breakage, > and have been for a long time. We might need to learn from them here, > and maybe we'll succeed. Any suggestion? Yes, that's correct. PR and advertisement is what lacked in the early Autoconf 2.5x releases. >> All I'm saying is, do not release Automake-NG for public use until >> Automake can warn of all incompatible uses, or almost all. >> > As I said, I don't believe this would be actually doable. Looking at GNU Smalltalk, I see: * warn for INCLUDES (vs. AM_CPPFLAGS) * warn for unknown *_XYZFLAGS variables (btw, why doesn't CAIRO_CFLAGS raise a warning)? * warn for treating _SOURCES entries with a custom unknown user extension as if they were header files as possible action items for Automake. And: * warn for suffix rules or otherwise do something about them * fix BUILD_SOURCES fork bomb, perhaps warn about it in advance (though I'm not sure I understood the root cause here) for Automake-NG. >> You have to evaluate each case separately of course, but a single >> project has already shown several cases where Automake _could_ be >> improved this way. >> > Are you referring to the Smalltalk "port"? If yes, I'm not seeing your > point honestly. Care to elaborate? See above. Paolo
