Re: Automake vs. Automake-NG

[Ralf Corsepius]

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