Re: Automake vs. Automake-NG

[Paolo Bonzini]

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
>