[Top][All Lists]

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

The future of Automake-NG (was: Re: [Automake-NG] typo whitelisting, an

From: Stefano Lattarini
Subject: The future of Automake-NG (was: Re: [Automake-NG] typo whitelisting, and Automake-NG vs. GNU make runtime)
Date: Thu, 23 Aug 2012 12:24:43 +0200

On 08/23/2012 11:07 AM, Paolo Bonzini wrote:
> So basically you want a version of Quagmire that supports
> Are you sure it isn't simpler to start from scratch?  Serious question...
Yes, I'm quite convinced that going through this admittedly more painful
"refactoring-based" rewrite is better, for two reasons.

  1. We can do a lot of work in reworking and reshaping the Automake
     codebase towards our final goal, all the while keeping it working
     with the existing testsuite and with some flaghship projects
     (coreutils, grep, autoconf, bison).  This greatly help to ensure
     we are not unwittingly break some important semantic, which gives
     me the needed confidence that "yes, we are building something that
     can work".  That kind of confidence is important.

  2. Even if Automake-NG 1.0 inherits a lot of Automake limitations, it
     will nonetheless offer some important new features and fix-ups; e.g.,
     no more "command line length exceeded" errors when there are lots of
     $(TESTS) or of files to distribute, support for wildcards in some
     primaries, less redundant make recursive invocations, possibility
     to define custom formats for the distribution tarballs, etc.  This
     might be enough to entice some projects to switch to Automake-NG,
     especially because, thanks to the fact that the new codebase has
     derived from a refactoring and reworking of the mainline one, the
     porting effort is expected to be very easy (in most cases at least)
     and involve little code churn.  [As a further hope, if they like
     what they see in Automake-NG 1.0, the developers might be more
     willing to jump on the wagon of an hypotetical new Automake-2.0,
     much more Quagmire-like, that would require a more thorough and
     serious porting effort, but that would free all of the power of
     GNU make for the developers to use].


reply via email to

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