While I was very optimistic about scons a month ago, I must admit that enthusiasm has faded a bit now that we tried out to use it for building Samba4. The idea behind it is good, but there are some issues when using it in real life (not all of them huge surprises):
- It assumes the relations between subsystems are compositional. If dir a is processed before dir b, dir a can not depend on any object files from dir b. This is a major problem for Samba.
- Running the configure tests (even with caching) each time you run a build takes way too much time for a project with as much tests as Samba (althought there are hacks around it).
- No easy way to add configure test functions.
- Python. This is a problem for Samba both because it means an extra dependency and not a lot of committers are familiar with it.
- Slow. Calculating checksums for each file rather then relying on modification times may be nice for those that have their sources on NFS, but it slows scons down a lot.
- Very much focussed on files and conversions between files - generating a list of init functions like we do at the moment is quite hard.
- While in theory it should be possible to generate a configure script and Makefile.in from a set of SConscript files, this proved to be a bit harder then I’d hoped.
Of course, it’s not all bad. Some good things about scons:
- Can transparently handle portability issues with different compilers, architectures
- The support for multiple build types is very neat and useful
- Automatic support for header dependencies
- Easy to extend. Scanning for dependencies, adding file types, adding compilers is not hard.
- Compositional to a large degree. Being able to put the list of files and the list of functions/headers a subsystem needs in one file in that subsystems dir is very useful.
I’m not really sure where to go to from here. I am no longer convinced scons is the right way to go, though using some of the ideas from scons in the current build system might be good.
Go Top