On 08/23/2012 11:07 AM, Paolo Bonzini wrote: > > [MEGA-SNIP] > > 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]. Regards, Stefano