Re: Automake vs. Automake-NG

[Paolo Bonzini]

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

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