Source Code Formatting, License Flamewars and Build System Issues

Tabs vs. Spaces

One of those never ending issues with source code formatting is the use of tabs vs. spaces. People seem to blindly argue for one or the other while not realizing that the best solution is to combine them in a smart way. That is, use tabs for indention and spaces for further alignment:

--->if (some_variable) {
--->--->long_function_name(first_argument,
--->--->...................second_argument);
--->}

This way everyone can set the tab width to their personal preference and the code will still look decent.

License Flamewars

As soon as I finished reading the mail containing a trivial ~10 line patch which was originally licensed under the GPLv3 for an otherwise MIT/X11 licensed program I knew this would result in a huge license flamewar. My opinion on this is pretty clear: whoever writes most of the code should decide it’s license. It could be so fucking simple but it seems like people like to waste their time by arguing over the same things over and over. Oh well.

Build System Issues

It turned out that the new dvtm-0.4.1 release has a problem in it’s build system which results in a breakage on the Debian server infrastructure. I changed an assignment in config.mk from = to += in order to provide an easier way to add extra flags. But because GNU make has a concept of different flavors of variables this doesn’t quite work as expected.

The problem is that the behaviour of += depends on the variable type it’s applied to. If it’s used on a variable which wasn’t previously defined it acts just like normal =: it defines a recursively-expanded variable. This means it’s value is referenced and recalculated whenever the variable is accessed. This is most often the case and the world is a happy place. However, on the Debian build infrastructure it seems like the LDFLAGS variable is predefined somewhere as a simply expanded variable which means it’s calculated ones upon definition. My Makefile is then called recursively and the value is appended again which results in a binary which is linked against both libncurses and libncursesw which obviously doesn’t work.

I actually prefer simple Makefiles as build system when ever possible because it should be simple, get the job done without too many dirty tricks and don’t waste valuable developer time. But it seems like you can shoot yourself in the foot pretty easily with Makefiles, Sigh. And no autohell is not the solution, it’s the problem ;)

Package management dependency resolution algorithms

I am playing with the idea of writing my own package management tool which could replace opkg on my ordered Freerunner once it arrives here. The last time I looked at opkg (it was actually still called ipkg then) it’s code was rather messy and contained things which I actually wouldn’t need. I would also like to have plugable backends. This would ease experimentation with something like sqlite. An integration with a SCM to provide rollbacks would probably also be interesting although maybe a bit overkill for a mobile device.

Anyway I am interested in the dependency resolution algorithms of existing package managers like apt, yum or smart. Unfortunately google didn’t really help me so far and digging through a pile of C++ code in case of apt doesn’t sound like too much fun.

As I won’t have that much free time in the near feature it should probably also reconsider helping in cleaning up opkg.

We will see what the future brings.

Marc