Slashdot Mirror
Make Out with SCons
Nice2Cats writes "I stumbled across this and can't find a mention of it here yet: SCons, a stable alternative for the vilified make. Built-in support, they claim, for C, C++, and Java, built-in support for use with SCCS, CVS, and BitKeeper, supports .NET, and works with Linux, *BSD systems, Windows NT, and Mac OS X. I'd love something to would finally get rid of the awkward (no pun intended) make, and having a system based on Python would make it double good. Maybe one of the serious C/C++ programers here could give a verdict on if this is the dragon slayer we've been waiting for."
I've been using make for like 10+ years. What exactly is the instability?
One thing I never liked about make was the dependence on whitespace in the makefile. Hopefully this Python-based solution will fi...uh never mind.
I predict Make will be around for a while still. I've used Ant but Make is fine for 90% of what I do.
After spending several hours trying to get make to do something complicated with shared libraries and multiple configurations, I started looking for a replacement, and stumbled across SCONS. It took me a few moments to download and install it, and a very short time to go from no knowledge of the system to having solved my problem.
Since then I've shifted several of my projects to using SCONS as the build system. I'm sure it's theoretically possible to achieve what I was trying using make, but I wasted many hours wading through man pages and howtos without success, and SCONS did it with almost zero effort.
I haven't tried using it on Windows yet, but my understanding is that you can use the same script under both platforms.
So, just one data point, but my experience with it has been 100% positive.
-alyosha
A build system for software should be easy, intuitive, transparent, etc. etc.
... yes, using workaround". The workaround may itself not work if pthreads isn't broken!
No. A build system for software must reflect the complexities what it is attempting to build. No build system for C++ programs can ever be fully "easy, intuitive, transparent, etc. etc." because there are C++ programs that aren't any of the above. Same for C.
Ever tried to compile XFree86 by hand from source? It must be possible, because Gentoo can do it, but I've never managed myself. While it can probably be made easier, the simple fact is that it's a complicated set of programs with a complicated build order and no matter how hard you try, it would take a full-fledged AI to make it "easy".
On the other hand, a pure Python project, even a large one, needs no special build system at all, because Python automatically compiles with few or no hassles (and what hassles exist can not be solved by a build system, they tend to be user error). Of course large projects are rarely all Python (building C extensions, compiling human-readable data representations into faster data or code, etc.), but since Python is more simple, the build system can be equally simple (or in this case, non-existant).
Make can be improved on, it's a decades old design with multiple layers of hacks jostling each other. A new, clean design can at least simplify away the parts of the build process that involve "fighting with make". But a build system for C can only become finitely simple, or you'll start to lose capabilities that C has because your build system can't handle them.
Small shell scripts and makefiles. Is more really necessary to call cc and ld or javac or whatever for each file in a directory tree? The differences among platforms can't be so dire as to require gigantic build automation tools, which introduce more problems than they solve!
Proof by counterexample: autoconf exists, therefore it is clearly necessary, because nobody would trouble to build it if it didn't address a problem. (Whether it solves it is another question, but given its vast popularity in the open source meritocracy I'd say the onus is on you to show that it truly causes more problems then it solves; every project that uses it is a vote against that statement.) You've clearly never written massively cross-platform code; grab a decent sized package, look at the output autoconf generates, and look at what the program does with it. Odds are every single line you see during configure, with the possible exception of some really standard ones that seem to be a standard part of the package ("CC works?"), is used somewhere in the program, especially lines like "Is your pthreads implementation broken?
One thing I see is a lot of people referring to how slow and unreliable recursive makes are, and they're completely correct. However, you can make your life a lot easier by using make but getting rid of the recursion, using a make with an 'include' feature. See Recursive Make Considered Harmful for nice write up on why recursive makes don't work, and how to do it correctly.
I converted our build system, and no-op builds went from a few minutes to about 5 seconds. Really. If I change one file, all the necessary stuff gets rebuilt, and none of the unnecessary. Every time. With a little gmake if-then-else (all in one place, not scattered around in a bunch of files), the same Makefile and segments work on Linux, AIX, and Solaris. And while the organization of the files is a little unusual for those who are used to the recursive style, they are just makefiles, no new syntax.
The downside? It pretty much requires gmake, but since this particular product is proprietary, we control the build machines. I don't think you can use automake...but I consider that a positive :-). You could use autoconf -- just put all the config stuff in one makefile fragment, and include it into the master.
We switched away from Make a few years ago. I looked at jam and other make replacements before settling on Cons, the perl-based precursor of SCons. We are now in the process of switching over from Cons to SCons (slowly), and so far it is working very well.
We are using it on Windows (MSVC and Intel compilers), Linux, IRIX, and Mac OS X (gcc and two versions of CodeWarrior). Handles all of those with ease. It can do things like properly handle dependencies on auto-generated source and header files, which would be a nightmare in make.
Some things like error handling and documentation need some work, but overall it is very solid. Automatic dependency checking, parallel build support, autoconf-like stuff, switchable tools, and easy to extend.
Yes, it requires python, but will run on just about any version back to 1.5.2, and doesn't require any python add-ons, so it's not too onerous a requirement really.
So far I am very happy with it; I'd suggest checking it out if make is making you crazy.
-- Tristero