Slashdot Mirror

← Back to Stories (view on slashdot.org)

Make Out with SCons

Posted by michael on from the scones-and-crumpets dept.

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

8 of 77 comments (clear)

  1. Re:Questions by Teancom · · Score: 2, Informative

    What does this mean? Will SCons somehow only work with languages that SCons has built in support for?

    Well, I haven't actually looked at scons, but in Make, there is only built-in support for a limited amount of languages. For instance, (maybe this has changed recently) with ObjC you have to define how to take care of .m file, as it doesn't know to compile them. .c and .cc files it knows to use CC on, etc.

    How does SCons compare to Apache's Ant?

    Well, the fact that it isn't based on Java or XML gives it a good head start :-)

  2. Already there... by KDan · · Score: 2, Informative

    Though i guess for now it only supports java - but there's nothing preventing you from writing custom tasks for it.

    It's called Ant.

    Daniel

    --
    Carpe Diem
  3. Re:Questions by pmz · · Score: 2, Informative

    Well, I haven't actually looked at scons, but in Make, there is only built-in support for a limited amount of languages.

    Adding implicit rules in make is not difficult. It's in the man page (even Solaris' crappy man page for make describes it well enough, and the system default rules file has lots of examples).

    Well, the fact that it isn't based on Java or XML gives it a good head start :-)

    Agreed.

    --
    Healthcare article at Kuro5hin
  4. Re:Does not solve the problem, but makes it even w by Circuit+Breaker · · Score: 4, Informative

    Spend some time to look at Scons. It's not a silver bullet, but it's a great step forward.

    It can, among other things, generate Makefiles or Visual Studio project files, or run the build itself. It does have "autoconf" style checks, which you can embed in the sconstruct/makefile. It's built for parallel make from the start. It does not suffer from network clock skew.

    And it has much better multiplatform support than any tool I've seen so far (automake/autoconf, make, qmake, tmake, cmake).

    It will take time to mature, and it doesn't solve the problem, but it does makes things much better.

  5. My SCons experience by vslashg · · Score: 4, Informative

    My SCons experience is that I like it a lot!

    We use SCons at work to build a huge, highly componentized project with upwards of 5000 source files. It's hands down the best experience I've ever had for building large projects. The other two big projects I've been on used GNU make and Microsoft nmake, and neither was satisfactory.

    The nmake-based system required running "nmake depends" before a build, and it simply wasn't reliable. Paranoia was high; when we hit a bug while developing, the first thing we did was a clean build, just to make sure we weren't looking at a build problem. (It was justified paranoia -- half of the time, it WAS a build problem :-) The recursive GNU make system was developed in-house and was much more solid, but painfully slow and absolutely horrible to use. It required Cygwin (which is evil, IMO) tools and bizarre mappings from source control, so it was hard to convince other people in the company to build our project.

    SCons was loads faster than our (admittedly bad) GNU make recursive build system, though noticably slower than our nmake build. With that cost, though, you get a correct build every time, something we never got in our "make depends" system. The paranoia is gone. SCons caches dependencies, so the cost for this accuracy isn't as bad as you might think. There were hiccups in the past, but the C++ dependency generation has been rock solid for at least nine months now.

    I have a little toy project at home with maybe 25 source files which also uses SCons. I use MinGW's gcc at home, and SCons worked well with it "out of the box". Right now all I do is maintain a list of source files to build just like I would with any other system, but the setup was painless, and it's awesome to know that I can write Python to solve any problems I might hit later.

    My big complaint with SCons is that a no-op build (running SCons when no source has changed) takes way too long on our big project, making iterative development painful. There's a command (-U) to build only components in a subtree of your file system, but that doesn't really speed things up much. Hopefully they can improve on that. That's about my only gripe, though.

    1. Re:My SCons experience by diewarzau · · Score: 2, Informative

      (SCons developer here)

      Yes, no-op build time is one thing we continually optimize for. Believe it or not, it's about 50x faster than it was at our initial release :)

      Also, there are several things you can do to sacrifice potential build correctness in order to speed up no-op build time, which are documented in the SCons Wiki. Unfortunately the Wiki appears to be on the fritz right now.

      Our philosophy is that, by default, we provide an absolutely correct build, which means recalculating/rescanning a lot of stuff every time -- the equivalent of doing a make depends;make every time (I venture that our no-op build time is faster than that!). However, if you know that you have not changed certain things, you can keep SCons from rescanning them, which is great for when you are in the compile/fix/recompile mode. I usually have an alias for "fast, not-so-accurate SCons" that I use for development and "accurate SCons" that I use for testing and release.

      Finally, there is a separate effort toi "daemonize" SCons. SCons has an as-yet-unpublished API that allows Python developers to put other wrappers around it other than the SConscript (i.e., makefiles-in-Python) interface that ships with it. The daemon effort keeps SCons around and rescans dependencies in the background a'la MS DevStudio, saving lots of time during the build. I believe the people on this project have seen as much as a 100x performance increase for no-op build times for large projects. Amazingly, it looks like we don't have a link to this on our page. I'll try to dig it up.

  6. A-A-P by LarryRiedel · · Score: 2, Informative

    Something similar/related is A-A-P from Bram Moolenaar of vim. A 1.0 version was just released last week. It is a make+Python kind of thing. There was short article about it at osdir a few months ago.

    Larry

  7. jam by Horny+Smurf · · Score: 3, Informative
    look at jam sometime. It's a free make replacer by the same folks who wrote perforce (the commercial cvs killer and bitkeeper competitor).


    The jamfiles are easy to set up, and much faster to calculate dependencies -- I built freetype via gnu make and via jam. Jam was done building before make had even started compiling!


    Also, props to perforce. It's proprietary (just like bitkeeper), kicks cvs's ass (just like bitkeeper), and is free for open source projects (just like bitkeeper). MySQL uses p4, IIRC. Unlike bitkeeper, you can get a single-seat version free (I use it for my internal projects, though CVS would probably suit my needs).