mr-edd.co.uk :: horsing around with the C++ programming language

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

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

Edd

[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.

(optional)
(optional)
(required, hint)

Links can be added like [this one -> http://www.mr-edd.co.uk], to my homepage.
Phrases and blocks of code can be enclosed in {{{triple braces}}}.
Any HTML markup will be escaped.