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

[Thomas Lord]

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
distributions.

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.

-t