Re: autotools gives autopain

[Vincent Untz <vuntz gnome org>]

Hi,

Le dimanche 18 d�mbre 2005 �3:58 +0100, Samuel Abels a �it :
> 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.

I don't remember having to debug anything for this, but it might have
happened. Maybe it wasn't so difficult :-)
I agree that if people need to debug often those things, then it might
be painful. But I'm not sure it's the case.

> - Makefiles are very large and thus difficult to understand.

I don't read Makefile. I read Makefile.am.

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

Those languages are not that hard, and people can help if necessary (or
docs, as Davyd pointed out).

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

Lot of overhead = lot of files or lot of space? If it's files, well...
is it that important?

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

True :-)

> - 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?)

This is more or less the same point than "new users need to learn to
write in multiple different languages": once you know these languages,
you can read them. But they're not the most pretty languages out there.

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

Stop. I don't want to update the build system every time there's a new
release of Scons. When Scons is ready, why not. But if it's not ready, I
won't switch before all the required features are in.

[...]

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

I do not want to update two build systems either :-)

To sum up my opinion: if people can show us it's ready and we don't have
to wait for features, then I won't see a problem with a migration. If
it's not ready, implement all the missing features and propose it
again :-) We have autotools now, they're working, so we can wait a bit
so that another system is ready to replace it.

Vincent

-- 
Les gens heureux ne sont pas press�