Il 21/08/2012 18:01, Paolo Bonzini ha scritto: > >>> 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
Ah, and * add support for AM_DIST_FORMATS. Paolo > 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 >