Yenya's World

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:
  File "/usr/lib/scons/SCons/Script/", line 581:
    return apply(method, args, kw)
  File "/usr/lib/scons/SCons/Script/", line 508:
    return apply(_SConscript, [self.fs,] + files, {'exports' : exports})
  File "/usr/lib/scons/SCons/Script/", line 239:
    exec _file_ in stack[-1].globals
  File "data/SConscript", line 21:
  File "/usr/lib/scons/SCons/Script/", line 581:
    return apply(method, args, kw)
  File "/usr/lib/scons/SCons/Script/", line 508:
    return apply(_SConscript, [self.fs,] + files, {'exports' : exports})
  File "/usr/lib/scons/SCons/Script/", 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/", 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 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.

Section: /computers (RSS feed) | Permanent link | 0 writebacks


Yenya's World: Linux and beyond - Yenya's blog.


RSS feed

Jan "Yenya" Kasprzak

The main page of this blog



Blog roll:

alphabetically :-)