[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 1.5.0.5 (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
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
- Re: Emacs-devel Digest, Vol 52, Issue 61, (continued)
- Re: Emacs-devel Digest, Vol 52, Issue 61, Chong Yidong, 2008/06/07
- Re: Emacs-devel Digest, Vol 52, Issue 61, Miles Bader, 2008/06/07
- Re: Emacs-devel Digest, Vol 52, Issue 61, Eli Zaretskii, 2008/06/07
- Re: Emacs-devel Digest, Vol 52, Issue 61, Eric S. Raymond, 2008/06/07
- Re: Emacs-devel Digest, Vol 52, Issue 61, Eli Zaretskii, 2008/06/07
- Re: Emacs-devel Digest, Vol 52, Issue 61, Eric S. Raymond, 2008/06/07
- Re: Emacs-devel Digest, Vol 52, Issue 61,
Thomas Lord <=
- Re: Emacs-devel Digest, Vol 52, Issue 61, Stephen J. Turnbull, 2008/06/07