[Top][All Lists]

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

Re: Emacs-devel Digest, Vol 52, Issue 61

From: Thomas Lord
Subject: Re: Emacs-devel Digest, Vol 52, Issue 61
Date: Sat, 07 Jun 2008 15:52:28 -0700
User-agent: Thunderbird (X11/20060808)

Eric S. Raymond wrote:
I'm very, very experienced with these tools.  Enough so that the fact
that they have spiky bits that still gash me occasionally is not an
indictment of me, it's an indictment of the tools.  Yes, they were the
best we could do at one time.  That time is long past.

I've recently had the experience of converting a large project from
autotools to scons.  The difference is amazing -- the LOC of the build
spec files dropped by a factor of 17, the interface is simpler, and
entire classes of build problems just disappeared.

As a point of amusement (and boasting, I guess) I'll mention that concurrently
with the original work to create autoconf I worked on a system (a cousin of
the one now more evolved at qef.com) where we got 2-3 orders or magnitude
reductions (100x..1000x) over Imake, fully audited builds, highly flexible
configuration support, efficient and parallelizable builds, and yadda yadda yadda --- all by building a handful of very tiny C libraries and simple utilities
that were far, far easier to bootstrap than a complete Python install.

That was, alas, proprietary code. (At the time, the number of paid jobs writing
free software was well short of 10.)

However, not only could we have done better back then, we can probably even
today do better than the advantages you describe for scons.

This is not to slag on scons but to suggest that if your efforts at cultural reform
make progress, it might be worth not simply leaping on the shiniest tools
du jour but, stepping back, considering what is actually achievable, and thinking
a bit about the goals.

My point isn't to advocate scons specifically, it's to illustrate how
much better and simpler modern tools (like scons, or WAF, por even ant)
are.  We're accepting a lot of breakage and hassles by not using them.
Don't pile blaming the victims on top of that.

One of my interests is in the possibility of "renewing" the original GNU project to build a complete system which is unix on the bottom but a lot more "lisp machine" in user space. Another of my interests is in exploring the possibility that the large gap between individual upstream projects and ready-for-use binary complete GNU/Linux systems can be reduced: it shouldn't be so labor intensive to create and maintain

This could be relevant to your attempts to improve the Emacs project's practices. Greater motivation for changes in tools might be found by considering how that can help create complete systems, if many upstream projects were to adopt new tools. Configuration and construction are closely related to source code management, auditing, aggregation of code, package systems, and more. Issue tracking that can be integrated across multiple upstream projects and downstream distributions
is another area to explore.

Adopting more ambitious goals might actually simplify advocacy for reform,
clarify decisions about tool choices, and have larger "pay offs" than trying to
do it one project at a time.


reply via email to

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