[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] Automake vs. Automake-NG

From: Paolo Bonzini
Subject: Re: [Help-smalltalk] Automake vs. Automake-NG
Date: Tue, 21 Aug 2012 17:02:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

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.


>> * 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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]