Slashdot Mirror

I found SCons about 10 years ago and use it daily. I only use make when I'm on a project that is already using it. Much easier than make and free threading. Because SCons is implemented in python you can do more than make, IMHO.

Try SCons. It blows the doors off of Make, and once you get the hang of it, is much simpler to use. It's also written in Python, and you write the "build files" (equivalent to make files) in Python. Real honest-to-goodness Python, not just some restricted kind-of-like Python stuff.

No matter what you do to it, Make is an antiquated pig. No offense to the GNU folks, who generally make the best versions of the traditional *nix utilities, and yes, you do need to keep Make around for backwards compatibility, yada, yada, yada.

What's really needed is a ground up re-think of how to create a build utility. A number of folks have tried it. I used to use SCons, and before that it's Perl based predecessor, Cons. The reason I'm not using them now has nothing to do with the software, which I though was excellent. The project lead's idea of alpha is what some people call final release.

I suspect the biggest problem to a widely used Make alternative is the sheer variety of options out there. Nevertheless, what are other people's experiences with build utilities other than Make?

I usually hand-craft my makefiles.

Have you tried Scons instead? Takes a day or two to get used to its different approach, but after that you will never go back. Make is a crude and error prone tool in this day and age. Also, Scons is a very solidly written and tested piece of software. Their idea of alpha is what most people call final release.

P.S. I'm not affiliated w/ the project in any way.

Maybe the best example is something that hasn't happened in the Linux world, though: a widely used high-level language.

Here's another one: the vast majority of FOSS projects are built with recursive make + GNU autoconf/automake. There are much better systems available (e.g. scons but probably some more recent ones) but picking an obscure build system means people are less likely to install your software, so none of them really get enough adoption.

Forget make...I know it's everywhere but it's a complicated dinosaur. As a C++ amateur I found SCons to simplify builds immensely. Plus, it's written in Python so your build scripts are just Python scripts.

Seriously. Install it now. Try the "Hello World" example and you'll be hooked.

Come help work on SCons!

SCons is an Open Source software construction tool—that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software.

It's under active development, and it's the best way to build C, C++, LaTeX, and lots of other types of projects. Build scripts are 100% python so you have the full power of a real language in your build. And... we need new developers to get to the next level! We have lots of ideas for ways to improve it. Come and take a few Easy-tagged tickets and implement them, you'll be amazed how easy it is to contribute. Plus we're friendly.

This year we replaced an old build system written in make with a (vastly superior) Python solution written from scratch.

"You haven't paid a thing for it; what do we owe you?" seems to be the cry of those developers who are faced with the fact that users don't like their project. You're right, you don't owe anything to users. But you know that you program for them. If you programmed for yourself, you wouldn't bother with configure files and auto-detection or any of that crap - it would just work on your computer. When users like your product, you love it, but as soon as they start complaining, "You get what you pay for!" Kind of reminds me of the Simpsons: "They've given you hours of entertainment for free...what else do they owe you?" But the fact is they make the show for the viewers, and when the viewers demand that their product be good or they stop using it, all of a sudden it's like you didn't even expect people to be partaking in your creation.

It comes down to this: you don't have to support users. Fuck 'em. But guess what, fuck you if you complain about some talking head saying how your product isn't ready for the big time. They're actually helping you - why don't you accept their criticism.

The major problem with CVS is this:

"I have a bug"
"That bug is fixed in CVS" ::downloads CVS::
"This CVS doesn't compile!"
"Sorry, we don't offer any guarantees with CVS"

Yes, the developers can't do anything if they've fixed the bug already. But it's frustrating to users, and unless you wanna say "fuck the users," the solution is obvious: fix the development process so "CVS" works - increase the speed at which users can use software. That's the major point the guy is making - software development is too slow. And I don't think it necessarily has to be fixed by increase developer man-hours. I think that too little thought is spent on preparing software for deployment, and that if a project put more of its focus on that, it would be more successful.

Here's one idea that might help: why the hell are people still using make and its evil cousins automake and autoconf?? You need serious gurus just to wade through all that muck. Everyone should check out SCons, because it makes life about a million times easier.

I've been a amateur drummer for 25 years, and have tried a few software packages, but here are the ones I actually find useful.

Under Windows, for overdubbing wav and midi I mostly use Cakewalk (warning: link contains annoying self-playing music). I use the cheaper Home Studio. They have a real product differentiation problem as Sonar is the expensive product, and then they market or bundle cheaper versions that may cover your needs just fine (its hard to tell from the product descriptions which features are grayed out). I use Cakewalk because the Windows drivers can be used in a very low-latency mode, and I always have a Windows laptop kicking around. I have not liked the scoring side of Cakewalk.

Also under Windows, I have used Sibelius (version 3 and 4). It is a phenominal scoring program that produces great looking sheet music. This is the only thing I do with a PC that I think is really better than without the PC. If you score with a program that plays back what you've written via midi, you can correct many mistakes on the fly. Sibelius is unfortuately still phenominally expensive for my uses, and I've never purchased it (nor has anyone I know).

Under linux, the equivalent of Cakewalk is Rosegarden. It is very impressive at the moment. Building it is a royal pain for me. It doesn't use your standard autotools driven make, it uses Scons (not in my distribution). Scons requires a Python module that's not available in the stable version of Python. Hey, people writing free software can use whatever they want, its just a shame some people won't try their product because of the barrier to entry. I've had latency issues with Rosegarden + JACK which I think can be sorted out but I have to decide if I want to run the tools as root or pull in the whole SELinux overhead + realtime module (no different than Cakewalk in Windows -- it does not work well as non-admin). Rosegarden's scoring is coming along but not quite there for me.

For scoring under Linux, I'm using Lilypond. Lilypond is phenominal, but many won't like it because its markup-based (like writing Latex). You have to go through the compile cycle to view what you've written, and dump midi to hear it. Fortunately for me, rythym section music is very repetitive. The quality of printed music it can produce is unmatched. I'm sure more programs will start using Lilypond as a processing back-end.

I'm not a newbie wrt computers - I've worked on and off with them since 1986. My focus these days is on art. I don't really want to learn more than I have to - and I'm speaking as a poet who uses scons and Abiword to build his website. My relationship with both is as a user. I report bugs. I don't fix the problems, I work around them. If I delved deeper, I wouldn't have any time to do what I what I wanted to do - write poetry, paint, draw. Focus.

I think linux systems are for those who wish to exchange money-up-front for time spent later with scripts, rpms yadda yadda yadda. I've spent my time in the trenches writing scripts to provide the missing bits of functionality. I've noodled with GIMP, trying to learn those extra bits and boy was it a PITA. It aint worth it if there are packages out there that will let you do it in less time and if they get it slightly wrong, well, there's slack in most things we do. My main aim in life is to produce something, not learn GIMP.

If I can afford it, my next box will be a MacOS X machine. Linux is for the birds.

[This is not a troll, it's a serious question from someone who's about to start a major db-driven web app.]

OK, everyone knows Java's a nonstarter these days. Ack, why did they kill it with Swing instead of a decent lightweight GUI (like wxWidgets or FLTK or something)? And they never got the memory usage under control.

But why Ruby and not python? What sort of errors is python prone to that ruby avoids? We have a bunch of python code here (scons and other stuff) and a bunch of older perl, and I'm reluctant to start a big web app in Yet Another Language. We all know python pretty well now. Is ruby going to be that much more maintainable? What about TurboGears for instance?

Also there seems to be a wider variety of libs available for python than ruby. And the python docs are very good. So I'm very interested to hear about the error-prone nature of large web-app development in python.

-- SilentTristero

While the preferred method would be simply use Linux, unfortunately my company is using Microsoft Visual Studio 6.0 with C++

Quit with the "Linux solves everything" cluelessness - Linux is not a C++ compiler. You mean to say that you think you'd rather develop under Linux than Windows. Okay, but then you have to decide what compiler (probably GCC) build system (Make, Scons?), version control (Subversion, CVS?) and what IDE or text editor to use (Eclipse, vi, Emacs?). If you're working in a team, it's going to be essential to at least standardise compiler and build system.

One thing you may be overlooking is that it's easy to duplicate what you refer to as the "Linux" toolchain experience on Windows - proving that there's nothing exclusively "Linux" about them. Thank GNU and the open source movement, not necessarily some guy from Finland:

* MingW32 is an excellent port of GCC to Windows. It probably has some difficulty compiling MSVC-specific code (I doubt MFC and .NET classes work), but you should ideally be using a cross-platform framework like wxWidgets instead anyway.

* Scons is a great Python based build scripting system. It leaves Makefiles in the dust as it allows you to use Python logic in the make process. I've personally run it on four different platforms (Windows, Linux, FreeBSD and Mac) and would never go back to Make. Although it helps, but is not necessary to be a Python fanatic (and if you don't know Python, take 20 minutes to follow the "Instant Python" tutorial linked on their site - it's possible you will fall in love with the language instantly).

* Eclipse is a nice cross-platform IDE that works well on Windows (and Linux, FreeBSD and the Mac). When used with the C++ extensions you get full syntax highlighting, project browsing and integrated debugging. Via custom project settings, it can be easily told how to build Scons projects instead of Makefile ones. (The only problem I've ever had working with Scons is requiring different settings to build Debug and Release builds, but I just set the IDE up to do Debug [work with that most of the time], then compiling and running Release from the command line).

And all of the above can be made to work nicely on Windows and Linux. If you switch to using those cross-platform tools on Windows, at some point your choice of platform becomes irrelevent and transitioning to Linux becomes extremely easy.

You can use Scons. A python based build system, has excellent dependency handling, flexible, has many built in rules for existing tools, handles the disparate rulesets elegantly, and solves a whole lot of problems.

I like it.

Seems like you should check out SCons. As far as I know, it takes care of all the gripes you have with Ant. The build scripts are in python, so you code in python right there. And SCons uses md5sums and does all the dependency checking for you.

If folk want something better than make, but don't want something so Java-centric. Have a look at SCons.

The software, as well as the confuguration files, are actually Python. But, you won't notice until your build requirements get quite complex.

Scons keeps track of dependencies using MD5sums on the tail nodes. This takes up a bit more processing time, but more than makes up for it with highly-parallelizable builds (SCons + distcc totally rocks), guaranteed correct builds (never do 'make clean' again!).

We've just converted a project from Make to SCons, and it's cut our build time by about 40%. I might even be able to convince our java guys to try it out, too :) (Yes, SCons handles Java as well as C or C++).

Network code is the one major thing SDL is missing that DirectX has...but once again, when you're working on a shoestring budget, how are you supposed to afford that?

Two points:

(1) SDL has a network library.

(2) The DirectX SDK is a free download.

Even Microsoft's command-line C/C++ compiler is a free download. Snag that, the platform SDK and DirectX SDK and you're set. The only thing you don't have is the IDE.

I use Visual C++ and DirectX at work for making multimedia applications - but there is an alternative. At home (because I'm cheap and also because I run Windows, OS X and FreeBSD) - I use the MingW32 which lets me use GCC, OpenGL and SDL and to make cross-platform code that compiles on any of my machines. I also use IBM's free Eclipse IDE with the C++ plugin and the Scons build system - because those also work everywhere.

..I think that XCode is awful. It's horribly unintuitive and enjoys separating you from your code. When you just want to build a damn executable it has you messing with build targets and all sorts of garbage that I will never care about. Even Apple calls XCode "A New Way to Work" (headline half way down the page). Sorry, but I liked my old way of working - you know, where I was productive and didn't have to learn the quirks of your stupid IDE. If I was ONLY developing for the Mac I might take the time to learn it.. but I'm not, so I will never waste my time on it.

Anyway, I found that I was most productive in OS X by treating it like Unix. I use Scons to build projects (no more Make for me), and I use Eclipse as an IDE (or occasionally Emacs as a straight editor when I'm doing something simple). Eclipse is originally a Java IDE (which is itself written in Java), but it has a C++ development extension available from their site and works nicely with standard tools like GCC and GDB.

So I use Eclipse to edit code, configured to call a custom Scons script (that I wrote and maintain to build the project) whenever I hit compile. The C++ Eclipse extensions understand how to parse error messages passed back from GCC, so while IDE integration isn't perfect, it works well enough to be productive. AND I still get command-line compilation if I don't feel like using an IDE that day.

Best of all: Eclipse and Scons are completely free and completely cross-platform (Scons runs whereever Python does). And I have an identical development environment on Windows (using the free MingW32 port of the GCC compiler), Mac and FreeBSD (although of course, my Scons script handles the multiplatform compilation issues internally, such as which system libraries to link with on different platforms).

(Disclaimer #1: I'm actually writing OpenGL applications via the SDL multimedia library - your milage may vary if you need a full UI, but I'd try wxWidgets if that were the case).

You poor S.O.B. - you're still trying to use Make. 1970 called, they want their build system back.

Try using Scons, a modern fully-featured build system for teh win!

is SCons.

Cool new python-based build tool: scons. More intuitive than make, imo.

1. boost-build v2 is the absolute BEST if you want to build C/C++ projects with multiple compilers & versions & targets--or even on simple projects that require a one-liner to feed into boost-build2 (normally taking 5-20 lines in GNU make).

Upside for boost-build2? Wraps compiler/linker flags in a generic language for many compilers and versions(gcc, msvc, bcc, etc). Also very easy for simple projects but truly shines on huge and complex projects. Jamfiles can inherit properties , requirements, targets, etc. from parent directories. Very very cool.

Downside to boost-build? Documentation truly sucks compared to other tools. Docs getting better but new users should prepare to unexpectedly find features they could've used to avoid hours of effort.

Boost-build v2 uses bjam but there seems to be a plan to add support for Python.

2. Scons is the next best thing to boost-build v2. The underlying language is Python but you don't have to be a Python expert to use it. And the documentation is much better than boost-build v2. However, it takes many more lines to get things done than boost-build v2 (which isn't all that bad considering boost-build v2 can do things in only 5 lines to replace a 40-line gnu makefile).

3. rake is a make-alternative written in Ruby. For all you recent Ruby converts, be sure to check it out. I love Ruby but I gotta admit, I don't see anything out there being better than boost-build v2 today.

GNU make served us well but it is time to move on to better choices that make us more productive. Just like cvs having served us well but svn and others being a better choice today.

SCons has automatic dependency checking built in, supporting many kinds of source files, but if it doesn't have what you need it can be easily extended.

SCons remembers the command line used to compile/build a given file, so it automatically figures out that it should rebuild that file if the command line arguments change. With Make it is very difficult to do that, so "make clean" is used much more often than it should be needed.

SCons is written in Python, and the SConstruct files it uses analagously to Makefiles are fundamentally Python scripts, but you don't need to know Python to use SCons. However, if you do know Python you can easily extend SCons.

SCons integrates well with Steven Ellis' 'nc' network compilation tool (though nc works with make also).

If you are also considering hacing at least part of the code work on both Windows and UNIX, having CVS or Subresion for source control and Scons or CMake for build control might help. Where I work we develop on windows, Linux and Solaris and we are using CVS & scons (scons/python seemed better than learning to use the cmake scripting language).

C:\>cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\>svn
Type 'svn help' for usage.

C:\>scons

scons: *** No SConstruct file found.
File "c:\python23\scons\SCons\Script\__init__.py", line 794, in _main

I'm not sure tying build-avoidance into the kernel and the SCM system is really the best way to do it. It does give you automagic dependencies, but at a price -- last time I used Clearcase we had to run a buggy two-year-old kernel because that was the last one Rational supported.

ccache and SCons give you build-avoidance too, without slowing things down or making everyone depend on a central server.

For a true cross-platform build system, take a look at Scons, Subversion and Data Debugger - I've used all of those on Windows (except DDD), Mac, Linux and FreeBSD - and they're fantastic.

When I tried using XCode, I found it seriously unfriendly - the UI is bizzare and makes no logical sense. I ended up trying to use XCode simply for editing code, before getting frustrated and using Emacs to edit and the command line to build.

If you have common filesystems (not necessarily even mounted in the same place, though this requires some unattractive transformation rules in the nc config file), and a synchronized clock (anyone heard of ntp?), nc will either definitely be faster than distcc, or will bring your NFS server to its knees (occasionally both).

I personally liked working with NetApp support explaining how 1 user doing 1 make could swamp a NetApp F840 (pushing about 1.6Gbit/sec over load balanced gig links to a cluster of 10 4-processor ultrasparcs). Our build, which would normally take ~1.5 hours (with -j4 on one machine) could finish in only about 12 minutes with nc.

When used across a workgroup, with distributed ccache, CCACHE_HARDLINK, scons and content signatures, it still rocks with a much more lame fileserver (it spreads the ccache jobs over the cluster, and most writes are just creating hardlinks on the server).

This may not help people trying to build random packages they picked up, but if you work on a large project in a workgroup environment, all of these tools:

• ccache
• scons
• distcc
• nc

-se

(My apologies for the shameless self-promotion)

If you have common filesystems (not necessarily even mounted in the same place, though this requires some unattractive transformation rules in the nc config file), and a synchronized clock (anyone heard of ntp?), nc will either definitely be faster than distcc, or will bring your NFS server to its knees (occasionally both).

I personally liked working with NetApp support explaining how 1 user doing 1 make could swamp a NetApp F840 (pushing about 1.6Gbit/sec over load balanced gig links to a cluster of 10 4-processor ultrasparcs). Our build, which would normally take ~1.5 hours (with -j4 on one machine) could finish in only about 12 minutes with nc.

When used across a workgroup, with distributed ccache, CCACHE_HARDLINK, scons and content signatures, it still rocks with a much more lame fileserver (it spreads the ccache jobs over the cluster, and most writes are just creating hardlinks on the server).

This may not help people trying to build random packages they picked up, but if you work on a large project in a workgroup environment, all of these tools:

• ccache
• scons
• distcc
• nc

-se

(My apologies for the shameless self-promotion)

I think nc can be used like distcc by redefining CC="nc gcc". However, more commonly it is done by putting $(NC) at the beginning of the build rules. Then you can use nc for any build rules, not just C compiles.

In addition to use with make, nc works well with SCons.

Moderate or post.. moderate or post.. hm.. post. This unbased Microsoft-bashing is getting on my tits. For the record, I love my Powerbook - but I also do cross-platform development on Windows, Mac OS 10 and FreeBSD.

Hey, Windows doesn't even come with a C compiler!

Apple's developer tools aren't installed by default either. So there's no difference. If you'll allow me to beat you with the cluestick(tm), you can download Microsoft Visual C++ directly from Microsoft.

Couple this with Scons and an editor even as basic as Windows Notepad (although I'm sure Emacs, PFE or something else would do better) - and you have a full development environment. Not a full-blown IDE, but there's nothing you wouldn't be able to do.

How much does Visual Studio cost again?

Zero. See link above.

But if you still want the IDE free - next you'll be complaining about stuff costing money and how you can't have free gasoline and nobody besides your mom will let you stay at their house without paying rent.

However, my Mac's user interface is enough better than Linux's to compensate.

KDE's come a remarkably long way. It's still not quite as polished as OS 10, although some tasks are easier to do if you're used to Windows (in OS10, I often find myself hunting for an option that I used once but forgot - I don't like the way it hides complexity). Anyway, try KDE if you've not used it recently.

But if you're still judging a relative usefulness of a computer over two very usable interfaces - especially when in the same breath you're complaining about command-line tools like GCC - I don't think you have the perspective to make a judgement call. A desktop UI should let you start and stop applications - anything else is fluff.

However, by that time they had already lost because they wouldn't allow clones, and IBM did.

IBM didn't "allow" clones. Compaq reverse-engineered the IBM bios - a hostile engineering technique. There's nothing stopping anyone from making an Apple clone - several companies did in the late 90's, but with Apple already being a fringe brand they lacked the marketing appeal to take off. Heck, even well-liked non-mainstream platforms such as the Amiga, BeOS and NeXT eventually died. A clone of a non-mainstream platform is probably doomed from day 1.

// ville

• cmake
  
• scons
  

Is Ant better than SCONS?
http://ant.apache.org/
http://www.scons.org/

Seriously, I'm just curious. I've heard a lot more about SCONS than Ant. For instance Blender is switching over to a SCONS build system.

The major problem is that a few compiler switches have changed. While I imagine it should be fairly easy to get the VC6 IDE to work - the incompatible switches, etc, could cause trouble.

The solution I would choose is to use a make tool that understands VC. Namely: Scons (Software Constructor). Keep VC6 to use as an IDE, but configure the IDE to compile through Scons (even if it's only by adding a command to the tool menu - this means you get the results back in the output window).

Scons is a cross-platform replacement for Make that is written in Python. One of the major wins is that the "Make" files themselves (actually named "Sconstruct") are Python scripts. You don't have to understand Python to use it - but if you do, it's an extremely powerful solution. Plus Scons supports -J (jobs) for parallel builds on multiprocessor (or hyperthreading) systems.

(1) Use Scons
(2) Use --jobs=2 (or however many processors you have).

Build times will be greatly improved - and it's cross platform as well.

In my opinion - especially if you have a complicated project - distcc isn't worth it. The machine takes so long pre-processing everything (including header files) - that you loose whatever advantages you might have with offloading the actual compilation work. It's especially useless with MSVC once you start using precompiled headers.

SCons is a next-generation build tool, or make tool, written in Python with strong cross-platform support, integrated autoconf-like functionality, a lot of stable features, and a growing user community. We're currently at 14K+ lines of non-comment, non-blank source code, and 32K+ lines of non-comment, non-blank test code.

We use a combination of two different testing methodologies: 1) Individual modules all have PyUnit unit tests (similar to JUnit, but in Python, of course). 2) The SCons application itself is tested using a custom testing module that manages creation of temporary directories and files, execution of the application, and checking against expected results. This custom module is actually a wrapper around a generic "test any script/command" infrastructure module that could be easily used to test other scripts and/or commands. (The command under test could be implemented in any language, not just in Python.)

I use the Aegis change management system to manage the SCons development and testing cycle. Aegis' primary value add (for me) is its management of the test cases and the testing methodology it enforces. By default, all Aegis changes must have one or more modified or new tests. The new/modified tests must not only pass when run against the new code, but must (by default) fail when run against the old code. This helps guarantee that your tests are good, and that your code isn't passing because you made a mistake in your test and forgot to call the new feature.

By testing in this fashion from day one, we've built up a very strong regression test base--284 test scripts at last count, each script containing multiple individual tests. This test base has become crucial to our ability to refactor (and refactor and refactor...) the internals as we add more features. Sometimes it takes longer, of course, to make a rewrite satisfy all of the regression tests, but when you're done, you can be pretty sure you haven't broken anything. And if you did break something, then you have to add or modify a test when you fix it, and that becomes another part of the regression test base.

The key to getting going with this kind of test-driven development (in my opinion) is making writing and executing the tests as simple as possible (but no simpler!). If writing a test is too difficult, then a lot of developers will simply avoid it. But if you can get them over the initial hump by making it easy to write tests, it gets downright addictive because you get all of this positive feedback when your tests show you that your new code works.

We'd be glad to have you check out the testing infrastructure we've developed for SCons, either for code you can actually use, or simply as a source of ideas. Feel free to contact the SCons development team if you have any questions.

You've obviously never used SCONS.

I second that: SCONS kicks ass!!!

More info: here

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

Something like SCONs perhaps, although I'm not sure python is the best language for this. Although it's possible, easy even, to write really ugly bash, it's a very good language for filing system manipulations, which is a large part of build management. There was another build system based on bash that was a LOT easier than autotools, but I can't remember what it was called! :(

Heh, hehe, okay.

According to Bagley's site, we should all be using Ocaml anyway. Who knows, he may even be right...

In reference to the Bagley test, Java was more performant than Python, true. But Python won over Java on both memory and lines of code. Also, his tests, as all artificial benchmarks, are both accurate only for the point-in-time and are only accurate within the limits of the test conditions themselves. More recent versions of both Java and Python are faster. On top of that, special-purpose optimizations exist for both Java and Python if you really need that extra spurt of speed -- think Jikes or TowerJ for Java and Psyco for Python. More to the point, though, Java may be faster than Python, but it isn't faster by an order of magnitude. The difference in speed between them is not enough to worry about -- if you really need that much speed, you won't be programming in either Java *or* Python, you'll be coding in C and assembler. Your performance argument is irrelevant.

Your libraries argument is somewhat more compelling. However, you may not be aware that there are two major versions of Python, standard Python implemented in C and Jython, implemented in Java. Using Jython, you can write Python that has full access to all of Java's libraries.

On top of that, I'll make a very rough comparison between the various projects on Jakarta and extant Python libraries. I don't think I've seen anything like this, as Python has a poor record for collating their libraries and apps in one place, so the effort is worth it simply for educational purposes, if nothing else.

Disclaimer: I am not terribly familiar with most of these projects, and they have varying states of completeness and maturity. I merely aim to show that analogs of the various Jakarta projects do exist in the Python world. Please feel free to peruse them yourself and come to your own conclusions.

Jakarta Ant -- PyAnt , SCons

Alexandria -- I don't know of any comparable Python applications. However, the individual components of Alexandria (doc generation, CVS access, etc.) are available: check out HappyDoc , and various modules for use with the Zope application server, including CVSFile

Okay, now I'm going to lump together a bunch of Jakarta projects. Individual authors and users of these projects will inevitably scream, but my justification is that they are all web application servers of one sort or another. Their purposes are all the same. They have many differences in approach, philosophy, scope, and implementation, but at heart, they are all web application servers or web application server frameworks. Those projects are: Avalon, Jetspeed, Struts, Turbine, Velocity, Slide, and Tomcat itself. Oh, and I might as well throw James in here, too. Python web app servers and frameworks are equally numerous, and several are in advanced stages of maturity: again Zope, Twisted, Webware, Quixote, CherryPy, and SkunkWeb. There are more, but I'll leave that as an exercise for the reader. Google is your friend.

Lucene has no real counterpart in Python. David Mertz has put together a text indexer and search program, available at his site, but it looks small compared to Lucene. There is also something called WePaSe, but there is no information on it aside from its freshmeat release announcement.

Gump also has no counterpart. Cactus has an equivalent in WebUnit and PyUnit. Log4J's Python copy is called, naturally, Log4Py.

ORO and Regexp provide regular expressions for Java. Python has regular expressions built in to the standard library.

OJB provides an object-relational bridge for Java, similar in concept to Sun's JDO specification. Python counterparts are Modeling , PyDO, which is a subproject of the above-mentioned SkunkWeb, and MiddleKit, a subproject of WebWare.

ECS, JMeter, and POI have no Python counterparts. BSF also has no counterpart, since it embeds a scripting language in compiled Java. Perhaps its "counterpart" is Jython. Likewise, BCEL has no counterpart, nor does Watchdog.

Taglibs has no direct counterpart. Instead, Python has Spyce, Cheetah, PSP, and probably close to a dozen other implementations of the ASP/JSP theme, each with their own library of tags. Lack of a standard is perhaps not a good thing, but the existence of bunches of competing implementations is not a bad thing. Perhaps the most direct counterpart would be Zope's built-in technologies, DTML and ZPT. ZPT has also been built out into a standalone version, SimpleTAL.

Jakarta Commons has too many small projects for me to want to research Python equivalents. If you are looking for something in particular, check the Vaults of Parnassus first.

As for Apache XML, Python has SOAPy and ZSI implementing SOAP, and DOM, SAX, and XML-RPC are built in to the standard library. 4Suite implements DOM, SAX, RDF, XSLT, XInclude, XPointer, XLink and XPath, and has an XML and RDF data repository and server built on top, which would make it very roughly equivalent to both Cocoon and Xindice. I don't know of any Python equivalents for Batik, FOP or XMLSecurity.

Python has relational database access through its DBAPI standard, with adaptors for just about every database. There are a number of object databases coded specifically for (and often in) Python, the most well known being ZODB, which was developed by Zope. There are adaptors for other object databases as well.

There are really two spaces where Java outstrips Python, and the second space is IMHO directly caused by the first: standardization, and J2EE. Python puts out a language implementation and a lot of very useful libraries, but does not have any standardization body like the JCP. The result is lots of fragmentation. Individual developers write their own libraries and applications that compete with each other while offering wildly differing APIs and programming approaches. There has been some push to organize, through the official Python SIGs, but their efforts, while noble, have not been massively effective. Only this month has an initial implementation of a Python library repository similar to CPAN been released. Kudos to Andrew Kuchling, who made it happen, but it is LONG overdue.

Regarding J2EE, the only viable competitor is Zope. Even then, Zope really doesn't address the same problem space. The shortfall here comes from a number of different factors: corporate buy-in, public perception, lack of an established problem-space solution, and lack of published standards. Zope is a great solution, and has been used by a number of high-profile companies, but its focus is different.

Well, I hope you find this comparison to be useful. *I* certainly found it enlightening.

While we're considering throwing away CVS, let's also throw out make. Check out Scons, a replacement for make. I have been using it for a few months on small projects and it's shaping up to be a really great tool.

Burn your Makefiles!

And when it is fully cooked, SCONS will also be a good choice.

It looks like the winning design proposals for a config tool (autoconf replacement) and a build tool (make replacement) are not being implemented.

The tool is called Scons, and it is much nicer to use than make. Instead of using timestamps to determine when rebuilding is necessary (which is very error prone in networked environments like NFS), it uses MD5 checksums. I encourage everyone to take a look at it.

Scons itself is based upon Cons, a build tool based on Perl.

Another developer has implemented SCCons.

Both are still in development, but roundup is being used by several organisations already. We hope to have a new release out next week that will fix some problems with 0.3.0 and implement some nice functionality too.

...but a tool called SCons has just been released. It is based on the ScCons tool that was in the Software Carpentry Contest, and is written by the same folk.

Glad to see SC is making progress. Another one of my favorite SC spin offs is Quilt, a replacement for the dated make. Additionally, SCons is a similar program which won the SC build competition in August 2000. Although I personally haven't used Quilt nor SCons, they appear to be well-designed pieces of software. Hopefully Software Carpentry will act as a catalyst allowing the creative juices of progammers around the world to create the most well-designed software possible. So far, I'd say it succeeded.