|
|
SCons rocks like Spock in a box!
I've been using SCons for a
project at work lately and have decided that it is not just a good
tool but rather an amazingly good tool. For a good description of the
shortcomings of make, see my favourite paper by Peter Miller, Recursive
Make Considered Harmful. (Interestingly enough, it turns out that
SCons uses Peter's Aegis
software configuration management system which also contains a make
replacement, called cook).
SCons has several extremely compelling advantages over regular and
GNU make:
- Automatic calculation of header file dependencies.
Most projects ignore header file dependencies, preferring to
either just ignore them or make a half-assed broken attempt to
represent them in make. This can be bad news for developers who
have to have enough experience with the project to know when to
run make clean after changing a critical header file.
Incorrect or out of date hand-coded header file dependencies are
slightly worse. You get the illusion of targets being rebuilt
after header file changes but still have to know when to rebuild
from scratch.
There are a couple of solutions to this available. IDEs like
Visual C++ automatically calculate header dependencies and
rebuilt targets appropriately which is great for Windows
programmers.
In the autoconf world, header file dependencies are usually
built around the creation of lots of little poos in your build
directory containing the output of gcc -M. These files
are included in your Makefile and you're off to the races. I
don't think this is an ideal solution, especially if you aren't
using gcc.
- Built in autoconf, automake and libtool-like functionality.
I think the whole m4 based templating idea is a nice hack
gone horribly wrong. While autoconf and friends serve the noble
function of making software packages more portable across
wierdly different architectures, they are quite slow compared to
the speed of compilation, and this makes the test/debug/fix
cycle for writing autoconf tests frustating and time-consuming.
Disclaimer: builtin autotools functionality may not be
completely equivalent to using the actual tools. I have had a
brief play with creating runtime tests in SCons but I'm not sure
how well this would scale to a large project with many runtime
configuration tests and --with style options.
- The ability to create separate build environments for building
different targets.
This is something really special. Traditional autoconf based
Makefiles have one set of environment variables - CFLAGS,
CPPFLAGS, LDFLAGS, LIBS are the usual names for these guys.
However, it is usually the case that every C file is built with
the same flags. Creating multiple sets of flags is rather
difficult. In Scons, environments can be copied and tweaked in
a couple of lines of code.
- Automatic rebuilding of targets if the build command changes.
This is actually quite a subtle feature and is something that
you might not realise is a problem in make. If I make a change
in a makefile, which targets need to be rebuilt? Make cannot
determine this and so you either have to do make clean &&
make, or do a partial rebuild by removing selected objects
or executables and rebuilding. SCons remembers the commands
used to build a target and if this changes, then the target is
rebuilt. If I write some comments, rename variables or
otherwise make changes that don't affect the build commands,
nothing is rebuilt.
SCons has some other advantages which aren't quite as eye-popping
as the above list, but still are worthy features to have.
- It's written in Python which means your variables, tests and
any other associated build stuff can be written in a
fully-fledged scripting language, instead of make's environment which
is pretty much a system for assigning values to variables. Indentation
trolls are not welcome. (-:
- Running scons dir where dir is a subdirectory
in your project will build all targets under that directory.
Neat!
- Unecessary rebuilds are avoided by using checksums to determine
whether a file has changed, rather than the timestamp.
- It works with Windows, not that there's anything wrong with that.
I guess to be fair I should add some negatives as well in a
pathetic attempt to seem balanced.
- Scons is written in Python, so it requires some knowledge of
the language to make full use of it. Fortunately Python is
pretty easy to learn and the syntax is very intuitive.
- Scons is a very different environment from regular make. There
is somewhat of a learning curve moving from one environment to
another.
- I'll probably run into some more limitations as I continue to
use the tool.
Make sucks, SCons rules. That's all there is to it! I would
unhesitatingly use SCons in preference to make for every new project
in the future. It should also be relatively easy to convert small
makefiles to SCons. posted at: 11:54 | path: /software/scons | permanent link to this entry
A Satisfied distcc User
You guys ROCK. Keep up the good work!! This was my first attempt at *any*
kind of distributed computing, and you-all have made it EASY. This is also my
1st-ever successful cross-compile; previous attempts to compile a kernel
intended for an Intel processor on AMD hardware, had failed. Thank you so
much -- distcc totally made my day.
It's pretty nice to hear about someone who is so happy with a piece
of software the first time they use it. I think that's quite rare.
posted at: 12:05 | path: /software | permanent link to this entry
Referrer spam
mbp discovers some referrer spam (here
and here)
which I think is pretty clever, although probably annoying for the
sites in question. I thought I would check to see how widespread the
problem was, at least with the particular script (Referrers 2.0) on the
yacht ad. Google says that there are only 132 sites that use the
script which isn't such a big number, but I can imagine someone
discovering a similar problem with some more popular software. All it
would take is a page or two of Perl and the results from google to
make a mess of a whole bunch of blogs. posted at: 11:06 | path: /internet/spam | permanent link to this entry
Boneheaded command line switches considered dangerous
Nick Moffit has had a
nice article published on the Linux Journal site updating a web page
about mutt macros to drive bogofilter. In particular there was some
confusion about the renaming (or rather swapping) of command line
options:
"This disastrous change violates the Rule of Least
Surprise espoused in Raymond's recent publication, The Art of UNIX
Programming. The section on the Rule of Least Surprise quotes Henry
Spencer warning against programs that appear to do things in a
familiar fashion when they actually do something very different. The
bogofilter command accepts the same command-line switches now as it
did in November 2002, but then, suddenly, March 3, 2003, was opposite
day."
We dropped bogofilter like a week old oyster after this boneheaded
manuever. In further ESR news, he is further
luxuriating in ignorance in a riposte to the community's reaction to
his first article. posted at: 16:47 | path: /rants | permanent link to this entry
Amusing Slashdot Misspellings
"Someone needs to charge SCO with raqueteering and extortion." posted at: 09:31 | path: /humour | permanent link to this entry | |