Re: autotools gives autopain

[Samuel Abels <newsgroups debain org>]

On So, 2005-12-18 at 01:37 +0100, Thomas Vander Stichele wrote:
> Hi,
> 
> first of all, I love python.
> 
> > 1. Scons is simply technically superior to GNU Autotools - with a big
> >    margin.
> 
> Saying this does not make it automatically true.  Some further
> explanation required.

I'll give it a try:

- The separation of Autoconf and Automake into two layers makes it
difficult to debug, because you can not easily tell which of the macros
generated a particular line in the Makefile.

- Makefiles are very large and thus difficult to understand.

- New users need to learn to write in multiple different languages (M4,
shell, and make's syntax)

- It ships a lot of overhead in every single package.

- Auto-generating stuff and integration with code generators is often
less than intuitive. (Thinking of Makefile.in.in.in and the likes.)

- The syntax of any of the languages does probably not meet modern
standards of readability. (I might add an IMO here, but may I doubt
whether many are going to disagree?)


Now I do not claim that Scons fixes all of Automake's issues. Scons has
a lot of problems of it's own. But, some of the most glaring advantages
of Scons are IMO:

- Most importantly, it can be fixed. Yes, it has a lot of problems that
need to be looked into. Many of them relate to the fact that not a lot
of functions are implemented yet. But there are no design decisions in
the way to make it work better. New releases come with new features and
it is constantly being improved. Autotools' problems, on the other hand,
are mostly design related and thus, haven't improved significantly in
the last decade. Yes, Autotools do work, but so does Scons.

- Through it's use of object orientation it is easier to create and
combine modules, and to share code.

- Choose to include functions from a large number of Python libraries.

- By using md5 hashes it determines more accurately/quickly when or when
not to rebuild a file/project. (make uses the mtime)

- Scons is very lightweight because it places only one single file in
each directory. That also makes it much easier to get into.

- I am not the biggest fan of Python, but I have to give them this: In
comparison with shell, or M4, the syntax is more readable.

- Drifting slightly off topic: The fact that a Scons installation is
required on the user's system can also be an advantage. For example, it
makes it possible (in theory) for users to run different frontends on
top of the Scons build system. For example, on one user's desktop
calling "scons install" (or clicking the SConstruct file) is going to
pop up a GTK UI, on another user's system the CLI is used.


All that said, I see no reason NOT to implement Scons in a project if
somebody is willing to do it. It can be done in parallel with Automake,
so you could still choose. Even if Scons is used as a replacement,
wrapping a Makefile around the Scons installer is trivial, so "make" is
still going to work.

-Samuel
-- 
 ------------------------------------------------------
|      Samuel Abels       |   http://www.debain.org    |
| spam2 ad debain dod org | knipknap ad jabber dod org |
 ------------------------------------------------------