I was reviewing the comments on the recent article describing the migration of KDE to SCons/bksys, and came across an incredible amount of disinformation.
The comments against SCons were usually of the variety that a system would suddenly be unsupported, or complaining that SCons uses Python, requiring an extra dependency.
Allow me to destroy those complaints. :-)
1. Bu-bu-bu-but think of all those AmigaOS users!!
The thing to realize here is that even with all of the baggage currently attached to KDE by the current build system, it is simply not possible to build KDE on systems that are more than slightly different from BSD or Linux, without patching the source and the build system. Indeed, the work that has been done using SCons has indicated that SCons actually makes it easier both for ports to Windows and Mac OS X. In addition, there is no reason that 97% of KDE developers and builders should have to suffer just because of the supposed benefits of the autotools. Nowadays any benefits we may have received are vastly outweighed by the disadvantages, and SCons is not only a “good enough” replacement, it is simply better, flat-out.
It is literally just insane how much extra time and space the autotools requires to support systems that KDE doesn’t run on, when SCons/bksys is able to provide everything KDE actually does need. I can distribute a SCons/bksys application, which includes SCons and bksys, in easily one-sixth of the space of an autotooled application (that does not include anything but the configure script and the required /admin directory). For smaller projects, SCons/bksys will beat the total configure/make speed probably by a factor of two, and although the effects will be less significant for larger projects, they’ll still be noticeable.
2. Bu-bu-bu-but SCons uses Python, it’s evil!!
No, Python is not evil. I’ll admit that it’s certainly not my favorite language, as Python has far too many warts to make me comfortable. But, unlike what the popular opinion seems to be about the autotools, they do not rely on just a POSIX shell. They also require a macro processor called m4, and the Perl language to be installed. The fact that POSIX shell is even used means that the scripts run are very slow since unlike with Python, a .sh script can’t tell what bugs/features are in the shell it’s being run by without running a great deal of tests and workarounds. We don’t need that cruft. To top it all off, it still practically doesn’t work without GNU Bash, so all those tests for esoteric shells are for naught, and do nothing but slow us down. This is to say nothing of the Perl dependency brought in by automake, or the fact that it’s practically impossible to actually use autoconf and automake correctly, no matter how many docs you read. In fact, with the adoption of SCons/bksys, KDE has a net reduction in languages since developers don’t need to know Makefile.am syntax, make syntax, m4, and bash syntax just to get stuff done.
Another thing is that the autotools also require good ol’ make. You know, the dependency tracker straight out of the 1980′s? It has its place, but there is a reason that we replaced make with unsermake, and that is because it is increasingly out of date with the reality of build environments nowadays. make doesn’t really support distributed compilation well, and the effects of automake tend to cause make to run very slowly.
So in conclusion, this is an astoundingly awesome change. For those who simply can’t live without all the megabytes of cruft that the autotools entails, feel free to maintain a KDE build system yourself. :-P
Posted by mpyne under Uncategorized | 1 Comment »
mandarin on 
Kerry on 
mama on 