Wed, 19 Jul 2006
A Slightly Better Wheel
In the world of Open source software, one can often spot a phenomenon, which I hereby name "A Slightly Better Wheel Syndrome(tm)". I often see this in bachelors' projects of our students, but sometimes also in the works of my colleagues or other computer professionals. The Slightly Better Wheel Syndrome is - strictly speaking - reinventing the wheel. It is less harmful than plain old reinvention of the wheel, because the result is - well - slightly better than the original. Except that often, in the big picture, it is not. Today I have seen an outstanding example of this syndrome.
I have read an article about driving simulation game named
VDrift. I wanted to try it, and (because
it is not in Fedora Extras), I wanted to package it. So I downloaded
the source, and wanted to compile it. There was no Makefile,
no configure, nothing familiar. So I have read the docs,
and I have found that SCons is used instead of make to build VDrift.
I have tried to find out WTF SCons is, and why should I use instead of
make. They have a section titled "What makes SCons better?" in
their home page: almost all features listed there fall to the category
"make+autotools can do this as well (sometimes in a less optimal
way)". Nothing exceptional, what would justify writing yet another
make replacement. What they do not tell you, are the
drawbacks. And those are pretty serious:
The first one is, that virtually everybody is familiar with
make. Every programmer, many system admins, etc. When something
fails, it is easy to find the right part in Makefile which
needs to be fixed (it is true even for generated Makefiles,
such as an automake output). Everybody can do at least a
band-aid fix.
The second problem is, that their SConstruct files (an equivalent
of Makefile) are in fact Python scripts, interpreted by Python.
So the errors you get from SCons are not an ordinary errors, they are
cryptic Python backtraces. I got the following one when trying to build VDrift:
TypeError: __call__() takes at most 4 arguments (5 given):
File "SConstruct", line 292:
SConscript('data/SConscript')
File "/usr/lib/scons/SCons/Script/SConscript.py", line 581:
return apply(method, args, kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 508:
return apply(_SConscript, [self.fs,] + files, {'exports' : exports})
File "/usr/lib/scons/SCons/Script/SConscript.py", line 239:
exec _file_ in stack[-1].globals
File "data/SConscript", line 21:
SConscript('tracks/SConscript')
File "/usr/lib/scons/SCons/Script/SConscript.py", line 581:
return apply(method, args, kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 508:
return apply(_SConscript, [self.fs,] + files, {'exports' : exports})
File "/usr/lib/scons/SCons/Script/SConscript.py", line 239:
exec _file_ in stack[-1].globals
File "data/tracks/SConscript", line 10:
env.Distribute (bin_dir, 'track_list.txt.full', 'track_list.txt.minimal')
File "/usr/lib/scons/SCons/Environment.py", line 149:
return apply(self.builder, (self.env,) + args, kw)
So what's going on here? With make, there would be a simple
syntax error with the line number. With SCons, there is a cryptic Python
backtrace, written in an order reverse to what anybody else (gdb,
Linux Kernel, Perl, etc.) uses. The line 149 in Environment.py is this:
148: def __call__(self, *args, **kw): 149: return apply(self.builder, (self.env,) + args, kw)
So what the error message is about? __call__() is defined with
three parameters, yet the message complains that it has at most four,
and it is called with five. Moreover, this is apparently called in some
magic way (there is no explicit call to the __call__() function)
from data/tracks/SConscript line 10, which is a call with
three arguments, and a call to something different that that
__call__() function. There is no way to fix the problem
without the deep knowledge of Python and SCons.
I have googled the error message, and found
this
thread, which said that it is possible
to build VDrift after commenting out the line 10 in
data/tracks/SConscript. But I still have no idea about what was
wrong, and wheter some edit of the line 10 would be better instead of
commenting it out.
So SCons is definitely another example of a Slightly
Better Wheel Syndrome. In a hypotetical SCons authors' Ideal World(tm)
where everybody uses SCons and everybody knows Python, it would have been
possible for SCons to be better than make+Autotools combo,
but in the Real World(tm), no way.
It is definitely harder to make an existing solution fit your needs instead of rewriting it from scratch. This is because it is harder to read the other people's code than to write your own. When using an existing solution, however, it is often gained more flexibility, maintainability, and features which "I just don't need" (read: don't need now, but in the future they might be helpful).
So the morale is: Please, please! Try to use (and maybe even
improve) existing widespread solution, even when it at the first sight
does not exactly fit your needs. Do not reinvent a Slightly Better (in fact
sometimes much worse) Wheel. The world does not need yet another slightly
better, yet in fact broken, PHP-based discussion board, PHP-based photo
galery, or a make replacement.