It's hard to believe, but it's already been half a year since I started using SCons for real. Seems like a good time to follow it up.
SCons is still very impressive. There are so many things you can do with a real language in the build script that there's no way I'll go back given a choice. Just today, I was writing a little test case for a Cygwin bug where large executables would crash. To test where the limit way, I created a little C file like this
char BLOAT_NAME[]={
#include "bloat.h"
};
with an entirely uninteresting bloat.h containing one million numbers with commas between them. Then, a SConstruct like this to build and link:
objects=[]
for i in range(100):
objects.append(StaticObject(
source="bloat.c",
target="bloat_%d.o" % i,
CFLAGS="-DBLOAT_NAME=g_bloat_%d" % i
))
Program(target="bloat.exe", source=objects + ["main.c"])
Et voila, a hundred object files were built from that one source file. With Make (even GNU Make), I don't know how to do it without depending on things like calling seq
from a $(shell)
and other icky platform-dependent stuff. Silly little example, but still.
A more serious use is in my big project (a half-secret reimplementation of the important parts of the system we're working on, which gives me 10 seconds edit-compile-debug cycles instead of 15 minutes), I wrote a little parser in Python for the build configuration files we have, and call that from my SConstruct. I loop over the list of source files and options that the parser produces, and add the corresponding nodes to the construction environment (i.e. I put StaticObject
s in a list and then pass the list to Program
like in the trivial example above). Works perfectly!
In a different side project, I also do multi-stage building, where I first build a tool that generates C code, and then build the generated code. The tool is wrapped in a Builder
, and the source files that are generated get dependencies on the tool binary, so everything runs in the correct order.
That said, SCons does have some shortcomings. The biggest one is lack of detailed user documentation. There is a user guide that gets you started on simple projects, but when it comes to the details of the provided builders, or exactly how SCons interacts with user-defined builders, the manual is silent. The only other documentation there is is the API reference, but it's very shallow, and you're better of reading the source. But that's of course not a proper solution, since the code only tells you what happens to work at the moment, and not what you can rely on for the future.
Another problem is release engineering. Until recently, there were snapshots from the source control, and there were releases that happened out of the blue once every year or so, with barely any maintenance done. Now, they seem to have changed a little, as there is an alpha version of 2.0 out. Hopefully, they will sort things out.
So, in conclusion: SCons still zooms. It zooms enough to get this die-hard Make fan convert. Trust me, I'm picky about build systems. Really picky. SCons is the first system I've used that is actually better than Make. It is a proper build system that tracks dependencies and all that. Yet it's dead easy to start using. You should definitely use it.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.