automake
[Top][All Lists]
Advanced

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

Re: Automake vs. Automake-NG


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

On 08/21/2012 06:01 PM, Paolo Bonzini wrote:

Ok.  So the question I'd like you to ask yourself are:

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.

Well, from a distro maintainer's view this a bad idea.

In Fedora we already are pushing around package maintainers to pass appropriate options to configure to revert this change, because silent make rules are non-suitable for building distros in batch jobs.

Making it the default in all automake-ng based packages, would escalate this already unpleasant situation.


But CMake is not almost the same as Automake, Automake-NG is.
Automake-NG is not Automake 2.0,
In other words, it is a fork with a backward incompatible API, a probably backward-incompatible runtime environment and a different target audience.

Somewhat exaggerated: Yet another tool the world has not been waiting for.

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.

Well, if automake-ng wants to be a success, feel advised to reconsider your opion. IMO, the reasons for the issues with the autoconf-2.1x->2.[456]x and with automake-updates are these not having provided/providing sufficient deprecation warnings and them often having suffered from tiny bugs which introduce behavioral breakages.

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.

Really? That's not how I recall the situation. I recall people turning away from autoconf in disgust because of the numerous incompatiblities and the often tremendous effort porting would have required.

Instead of "jumping" the "upstream autoconf train", they waited for the things to settle/stabilize (some projects are still waiting today) while others started to look out for alternatives (cmake, scons) - Many switched away.

Ralf





reply via email to

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