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

3 of 77 comments (clear)

  1. stable alternative to make? by Anonymous Coward · · Score: 3, Interesting

    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.

  2. SCONS is awesome by alyosha1 · · Score: 5, Interesting

    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

  3. Re:Questions by Jerf · · Score: 3, Interesting

    A build system for software should be easy, intuitive, transparent, etc. etc.

    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? ... yes, using workaround". The workaround may itself not work if pthreads isn't broken!