Re: Automake vs. Automake-NG

[Paolo Bonzini]

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