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

Comments

Questions

[Zach Garner]

Integrated Autoconf-like support for finding #include files, libraries, functions and typedefs.

Is SCons viewed as a replacement for Autoconf and Automake, or just a replacement for Make?

Built in support for...

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

How does SCons compare to Apache's Ant?

Re:Questions

[pmz]

The good thing about doing ant conf files in XML, si if they change the format, you can use xsl to transform ALL of your xml to a new format.

Layers upon layers of complexity. XML, XSL, Java, Ant Schemas...all for compiling a program. My sig is appropriate, here, too. A build system for software should be easy, intuitive, transparent, etc. etc. There has yet to be a replacement for make that has these attributes (makes tab syntax really isn't that big of a deal, either, even though that's what most people latch onto when complaining about it).

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!

Re:Questions

[sporty]

Layers upon layers of complexity. XML, XSL, Java, Ant Schemas...all for compiling a program. My sig is appropriate, here, too. A build system for software should be easy, intuitive, transparent, etc. etc. There has yet to be a replacement for make that has these attributes (makes tab syntax really isn't that big of a deal, either, even though that's what most people latch onto when complaining about it).

Whoahoahoa.. no. Blatantly wrong. If ant 1.0 used one particular XML format, and you upgraded to ant 2.0, to go from an ant 1.0 file to 2.0 file, you'd apply an xsl style sheet ONCE to upgrade it all. Any future XML you write would be in the 2.0 format. Simple as that.

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!

Bash? csh? sh? tcsh? bash 2.0? Which shell are you suggesting is usable across them all?

ant is just a program, just like make is. You run it against a config file of a certain format, just like Makefiles have their own format. Ant is no more compicated than make. hell.. you can use the core stuff from ant to run any program across many files, just like make. The targeted tasks are just to make those easier.

Re:Questions

[Jerf]

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!

No Screenshots?

[Randolpho]

How am I supposed to know if I like the look and feel if there aren't any screenshots? :D

stable alternative to make?

[Anonymous Coward]

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.

SCONS is awesome

[alyosha1]

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

Re:Does not solve the problem, but makes it even w

[Circuit Breaker]

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.

My SCons experience

[vslashg]

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.

jam

[Horny Smurf]

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