Hi, Le dimanche 18 décembre 2005 à 03:58 +0100, Samuel Abels a écrit : > 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és. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
