Trying SCons

A while back, I did some trivial things with SCons in an attempt to help someone that was trying to cross-build some software that used it. I’m not sure if I actually helped any, but it involved reading a little bit about SCons, such as what it is and does.

The impression I was left with, was that SCons is a replacement for good-old Make, that does all the autotools things itself (so that it also replaces ./configure etc.) – including some advanced features like automated dependencies – with a simpler basic configuration syntax that is actually much more powerful (really being a Python script with some custom functions – not that I know much Python, but that’s not really required).

Especially the automated dependencies bit sounded really interesting to me, along with the simpler syntax. So, since I’ve been thinking about and looking at build systems recently (due to trying to get HIDAPI to build a shared library on Linux), I decided today to go ahead and try to use SCons for my own project.

This went well enough at first; I had some issues getting things to build initially, but that was obviously caused by needing it to find HIDAPI in a completely non-standard location – so I read some more documentation and figured out how to point it at the directories with the hidapi.h and libhidapi-hidraw.so files, which wasn’t really all that hard – just a couple of parameters to set in the right place.

That let me build my libraries well enough, using a globbing function to list the sources to put into them (it figured out things like -fPIC on its own) – but linking my programs failed. To fix that, I had to not only list the current directory as a library directory (so it could find my library), but also had to tell it explicitly to link against both the tempered library and the hidapi library. At this point, I figured, OK, so its automatic dependencies aren’t quite good enough to figure things out when the libs aren’t installed yet – a little disappointing, though nothing major – but one of my programs still failed to link.

This was where the first big disappointment came, as the problem was the math library – libm – which I also had to list explicitly in the list of libraries to link with. This is a bog standard system library that exists on just about all modern systems, and is very well known – so that the automatic dependencies didn’t catch it stretched my suspension of disbelief past its breaking point, leaving me with the realization that I had completely misunderstood.

Apparently, the automatic dependencies thing is only for the files within a project – meaning that a change to one of the source files makes it rebuild all the objects that depend on it, without me having to explicitly list the dependencies. I had thought it also recognized the standard inclusions and automatically added the necessary libraries to the list of libraries to link that program with.

Oh well, I kept going anyway – not like my project needs all that many libraries, and I still liked the syntax better than that of Make – and this latest addition got it to build.

But when I tried to run the resulting program (well, I ran ldd on it), it didn’t find my library. It did find the HIDAPI library, which was in the same location, which worked fine with my Make-based build. It was looking for libtempered.so instead of libtempered.so.0 … Sigh, SCons isn’t setting the soname on the shared library.

This turned out to be a somewhat worse problem, as I could find no built-in platform-independent way of setting the version for the soname, or indeed the soname itself. I did eventually get it to set the soname, by putting a linker-specific flag into the parameters it sends to the linker, but that’s rather contrary to the spirit of SCons, which is meant to have platform-independent recipies.

At this point, the SConstruct file was starting to approach the size of the Makefile, and while it might have been more platform-independent (I’m not so sure), it didn’t have all the same features (for one, it didn’t build static versions of the utilities).

All these things taken together, and some pointed out by others (like the lack of standard targets, and awkwardness with using it for installation), have lead me to conclude that, basically, my project is at once too small and too complex for SCons to be significantly better than plain Make (too small to need the automatic dependency resolution, yet wanting to build proper shared libraries), so I’m better off not adding the dependency on SCons and instead sticking with Make for now.

While this experiment wasn’t exactly a success, I wouldn’t say it was a failure, either. It didn’t result in my project actually using SCons from now on, but it did disabuse me of some misconceptions, and left me knowing more than I did previously, even if the summary is only that SCons isn’t as good or as useful as I thought.

Oh well.

The next build system I look closer at will probably be CMake, as that seems to be what signal11 wants to use for HIDAPI, and I’ve said I’ll help with that. Hopefully, it’s not as disappointing.