Introducing the slam build system
[22nd February 2007]
I've spent countless hours battling with makefiles in the past. There are so many problems with make, it's beyond a joke. I wanted to build my software on multiple operating systems using a number of very different compilers in a number of different configurations (debug, release, profile, test, etc). I wanted my dependencies managed for me. I wanted my build scripts to be low maintenance. This is something that make just couldn't do for me.
The itch was too big to ignore. In scratching it I came up with slam. I hope you find it as useful as I do.
Numerous others have obviously had the same itch and I spent a good few months investigating systems such as Boost.build (version 1 and version 2) and SCons but neither quite did what was needed.
Boost.build has great support for multiple compilers out the box, but it's syntax and implementation is somewhat arcane, as it is based on Jam. It also has no support for pkg-config, which is something I really need since I use gtkmm for most of my home-brew GUIs.
SCons is really flexible, but rather buggy and slow. Writing a SConstruct that allowed me to select a compiler at runtime was a nightmare and there was no way to specify vendor-neutral compiler flags; I couldn't just tell it that I wanted to turn on the compiler's optimization facilities. Instead I had to set up the mappings myself for each compiler. Gah!
And so slam was born. It isn't the biggest and best build system available and it's only suitable for C and C++ projects, really. But it does exactly what I want and does it quite well. It's implemented in Python and so should run on your favourite operating system. So far there's support for MSVC 8, generic GCC, MinGW GCC and Apple's GCC. I'm going to try to implement toolset code for MSVC 7, Borland C++ and Digital Mars compilers in due course.
If you're interested in giving slam a go, then by all means have a read of the documentation and put it through its paces. It's still rather rough around the edges, but it's usable right now and I'd be interested in hearing what you think!
I can finally wave bye-bye to my makefiles!
Comments
[10/03/2007 at 01:53:00]
That looks interesting. How would you propose a merge? I don't use Java as much as I used to and I'm not particularly familiar with Maven so I don’t know how much I could help with porting the code. I assume that the Python code couldn't be used more-or-less directly?
I'm currently refactoring the slam source code to make it more readable and flexible, which I hope won't take too much longer. Once it's done it should be pretty easy for someone such as yourself to cherry pick the parts needed for a given project.
I'm happy to describe the architecture of slam and help with you deciding on which bits are relevant for your project, but I'm not sure that I'll be able to contribute (much) new Java code.
All original content copyright© Edd Dawson.
All source code appearing on this website that was written by Edd Dawson is made available under the terms of the Boost software license version 1.0 unless otherwise stated or implied by the license associated with the work from which the code is derived.
Ale
[08/03/2007 at 16:50:00]
Hi
I came across your site via the post [1]
Please have a look to
http://java.freehep.org/freehep-nar-plugin/
which will be moving soon to
http://xircles.codehaus.org/projects/native-mojo
We should try join our forces!?!
[1] http://groups.google.com/group/comp.programming.threads/browse_thread/thread/2b6d6ac0c2e2622a/f5cdc335cde1de29