Automake and I have been friends for a long time. Â We’ve loved, we’ve laughed, we’ve cried … A lot! Â Automake is the de facto build system on unix (especially linux) systems. Â I use it in almost all my projects. Â Automake isn’t too hard once you stop copying someone else’s Makefile.am’s and configure.ac’s and actually take a few minutes to learn what’s going on. Â Although lack of documentation and that horrible language called m4 is a huge turn off. Â Although I really like the way automake feels, I’ve felt that it needs to be modernized with a simpler syntax, more cohesive tools, and a decent scripting language. Â This and the fact that it doesn’t play nicely under windows (unless you want to build with gcc in cygwin or cross-compile), has left me looking for something new.
2 years ago when I changed direction and started working on different projects, our regular windows builds ceased. Â I somehow had become the official builder + releaser guy in our lab. Â Every once in a while we’d need to get a new development build out for a windows user. Â I’d have to step in, remember how everything worked, fight the system, and eventually come up with a build.
A long time ago, I had everything cross compiling in a chroot environment. Â This was nice since I had a shell script which would do everything for me, except the final freezing of python which had to be done in windows. Â Over the years the dependencies in the chroot environment became out of date, and things stopped building. Â I was busy and never updated the machine, and eventually it was re-purposed for something else.
Then came the windows vmware image with mingw setup (we didn’t need to depend on cygwin for any posix stuff). Â This was okay, but more difficult to script, and became a much more manual process which also became a constant update headache.
Recently we wanted to stop building under gcc and move to using visual studio’s compiler. Â The build system had stopped working and we were running into issues when creating our python modules. Â Automake + libtool would not play nicely with Visual Studio’s compiler, so I started looking at alternatives.
- CMake: The only experience I have with it is building vtk, and it just pisses me off … out
- BJam: Interesting. Â Doesn’t have a configure stage but can use autoconf … intersesting, but didn’t see much of a payoff
- SCons: Â Seems to have gained the most popularity and works well under windows + unix
After some initial testing, I decided to move our projects over to SCons. Â SCons has made some things very easy, like building with Visual Studio’s compiler and handling SWIG. Â However, SCons is contantly doing things to annoy me. Â Here’s my list of personal annoyances:
- Make it feel more unixy. Â Everything about SCons feels foreign
- By default everything should have an install and uninstall target. Â None of the alias stuff, and I still don’t have uninstall going
- Something to handle .in files. Â We use these all over the place for creating run scripts, pkg-config files, etc.. Â Automake will automatically read a .in file, replace everything surrounded with @ and write the the new file
- SCons config.h support is terrible. Â Hell, I couldn’t even get it to actually write the config.h file until a create a default target depending on config.h
- Running configure is essential. Â We build our software on all different OSes with very different configurations. Â We must be able to find what packages are available and where they. Â If not available, we need to error out or build around it. Â SCons has some configure support, but it’s severely lacking. Â I also hate the fact that the configure step runs every time you build. Â It should be run once and then automatically if a dependency check has changed. Â I managed to sort of get around this by creating a dummy configure target that automatically runs the first time, and then dumps off the settings. Â Don’t get me started on SCons’s crappy Variable support.
- Better support for pkg-config. Â Both using pkgconfig to find packages and support for creating .pc files
- SCons by default doesn’t use your environment. Â I understand that they want a clean environment, but this means override CXX with ccache is ignored. Â This also means that programs in your extended PATH are ignored. Â Even things like overriding the PKG_CONFIG_PATH to find pkgconfig files is ignored. Â Annoying!
- Lots of minor things i’m not going to get into
There are plenty of good things about SCons. Â I really like working in python, and it’s nice that it works well in windows and unix. Â Overall, SCons is mostly working for us, but I am in no way satisfied with it. Â I suppose someday I’ll have to write my own build system.