[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The future of Automake-NG (was: Re: [Automake-NG] typo whitelisting, an
The future of Automake-NG (was: Re: [Automake-NG] typo whitelisting, and Automake-NG vs. GNU make runtime)
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 configure.ac.
> 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].