[Top][All Lists]

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

Re: Automake vs. Automake-NG

From: Paolo Bonzini
Subject: Re: Automake vs. Automake-NG
Date: Tue, 21 Aug 2012 18:03:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

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


> 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

reply via email to

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