Il 21/08/2012 16:32, Stefano Lattarini ha scritto: > Bottom line is: we want to make it clear that Automake-NG is something > different from Automake -- albeit mostly compatible, deliberately, and > with very, very similar design and API; and that a transition between > the two won't be seamless -- albeit it is expected to be simple and to > involve only little churn.
Ok. >> * using INCLUDES instead of AM_CPPFLAGS could be deprecated loudly in >> Automake 1.13 >> > This is a good idea. Want to attempt a patch? Otherwise, I will write > it myself in the next days. I doubt I have time, unfortunately. :( >> * pattern rules should be advertised over suffix rules in Automake-NG, >> but suffix rules should be accepted >> > They are! It's actually simpler to accept them rather than to reject > them, since doing the latter would entail more Automake-runtime > processing, which we want to avoid. The only important difference is > that you'll have to declare '.SUFFIXES:' yourself, as Automake-NG do > not do it automatically for you anymore (a change which I now see is > not listed in the NG-NEWS file; will fix shortly). 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? * Even if not, could a missing '.SUFFIXES:' hide bugs? Would you consider adding a warning for missing ".SUFFIXES" in Automake, too? 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! >> This way, people will slowly convert their code bases to the style >> preferred for Automake-NG. If the only point that remains is the >> variable typo detection, that's fine. But all semantic changes should >> be suggested by (non-NG) Automake for developer to even consider taking >> Automake-NG seriously, IMHO. >> > I disagree. After all, people are taking CMake seriously, and that > is hardly compatible with Automake. 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. 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. >> I apologize for the useless complaint if you are already doing this; >> > Please don't. I find this exchange very useful and informative for my > own understanding of the status and direction of Automake-NG. > >> please let me explain my worries. The lack of a clear upgrading path >> (and bugs in autoupdate, which took a while to get right) was what >> caused problems in Autoconf 2.50-2.53, compounded by the lack of >> awareness about Autoconf/m4 best practices. >> > The difference here is that people *should* understand that Automake-NG > is not meant as an "Automake 2.0", but as a new projects with different > aims, and thus different idioms, usages, strengths and weaknesses. People won't. :) > This is the point I want to drive home, to avoid another transition > debacle like the Autoconf one. Here's an honest question: if > Autoconf 2.50 has been called "Autoconf-NG 3.0 alpha", and finally > graduated to "Autoconf-NG 3.0" with what we know as Autoconf 2.60, > do you think the transition would have been less painful (I really > hope the answer is yes, of course). My answer is that the two cases are different. On one hand, there was no obstacle between a possible graduation of Autoconf-NG 2.5x to Autoconf, like the GNU Make dependency could be for Automake-NG. On the other hand, it would have been nigh impossible to provide the smooth deprecation path that I'm suggesting. All I'm saying is, do not release Automake-NG for public use until Automake can warn of all incompatible uses, or almost all. >> It can provide good error messages and a clear upgrading path. Please >> _do_ provide it. >> > I hope to finally do that, but it will be in a form of a how-to and a > set of recipes rather than an attempt to shoehorn Automake-NG semantics > back to Automake. The latter sounds too slow and too dangerious. 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. Paolo
