Scons looks as useful and portable as CMake so I'd say it will be clear improvement over autotools :-)
I agree. m4 is only useful for m4 pros.
Note though that the KDE project had a dual build system for a while (Scons and Cmake) and they finally opted for Cmake because:
Interesting. I do not know any of them now, but
1) it was simpler (take a look at a typical CMakeList.txt)
I actually do not like, just for syntax, the COMMAND(arg arg1) (without comma), and prefer a more function like style. And, maybe in SCON command is a function that I can look up...
2) it was faster
I think both are much faster than autoconf.
3) KDE devels had to implement a lot of feature on top of Scons but Scons developers weren't interested in them so that was a fork.
lyx is smaller... I guess we do not need many.
4) CMake developers were very helpful and added a lot of support for Qt, MacOSX and Windows for KDE needs (I am sure they would help with the port reading a bit their mail archive)
I will see.
5) last but not least, Scons is stuck to python 1.5 or something.
So you mean I have to write in python 1.5 for its extensions? I guess scon tries to make itself runable on old systems.
Personnaly I like the CMake approach better because they delegate the compilation step to the sytem: Makefile for Unix (or Mingw), MS Visual studio project for MS VC++ users. This approach allows people working with different systems to work cooperatively without any porting porblem.
These look nice. But you know I am biased to python. Because if I have to write an extension, I can do that immediately with python, with all the help from python modules, not something I have to learn from scratch, however simply it may be. I will evaluate both when I get a chance. Bo
