David Philippi <[EMAIL PROTECTED]>:
> There are new versions of autotools from time to time, I wonder wheter they
> don't add new nice features most people don't know anything about...
They add new macros and tests, sure. The problem is that the
underlying architecture of autotools is so bad, and so chained to its
own past, that the main effect of adding features is to make it more
top-heavy and brittle.
What do I mean by "bad"?
Well, let's start with the implementation -- in a mix of shell, m4,
and (nowadays, I think) some Perl behind the scenes. Shell and m4
made sense when autotools was first designed; back in those days they
were the only portable scripting tools we had. But it's that mixture
of languages (m4 being used to generate shell procedures) that makes
configure.ac syntax so weird and fragile and hard to maintain.
Anybody (not utterly insane) writing an autotools equivalent today would
pick one of the evolved scripting languages to do it in: Python, Ruby,
or (if it actually existed in a stable and deployable form) Perl 6.
The advantages of writing the entire tool in one Turing-complete
language would be huge, and are quite visible in SCons and WAF.
Let's continue with the two-level split between autotools and
Makefiles. This is a complexity disaster, and the cmake people
should be seriously slapped for perpetuating it. Have you ever
actually *looked* at the square meters of generated cruft in
src/Makefile? Go ahead, I'll wait...
All that crud is *utterly unnecessary*. it's strictly an artifact of
the generator/makefile split, of trying to stuff build-time recipes
into the extremely weak execution environment that is all make
provides.
I could go on for pages. I've been wrestling with autools ever since
its earliest ancestor, the config scripts in GNU Emacs c. 1987. It
was horrible, but in a certain sense necessary, then. Today it's
even more horrible -- and completely unnecessary.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
