Thursday, October 01, 2009

Even more gloom

You know, I wouldn't have thought it possible for today to be worse than yesterday, work-wise.

But it managed.

We have a reasonably large order for a new project, for which I have already designed the hardware, and so I just need to write enough of the software to be sure that the hardware works so we can safely order the PCB's, etc, for manufacture. Though actually I suspect that once started I'd actually write the whole thing so that we can provide an early sample for the customer to evaluate.

So, I duly set up the project and start to write code. Or at least I would, except that for some unknown reason the thrice-damned compiler for one of the processors involved (a Jennic RF device) has stopped working. Yes, the software has rotted. Or, to be more accurate, something I've installed (some other version of gcc, probably) since last time I used it (a few months ago) has messed with the path, or the environment, or whatever, and killed it.

Not that it gives a helpful message, you understand, no, the only indication is an essentially meaningless error from the make process, emitted from one or other of the (slightly incompatible) versions of the fucking make utility I have to have on this system. So once more, if I can work up the energy, I'm going to have to delve into makefile hell, find out what the bastard thing is moaning about, why it has changed, and what to do to fix it. And this, no doubt, will fuck with something else on the system and make that stop working with some obscure problem I will trip over later...

Oh, gods, how I detest relying on other people's development tools. I'd say most of 'em were designed by arseholes, but the truth is that most of 'em weren't designed at all and are just the product of generations of open-sore bodging.

So, what to do? There's something to be said for the idea of using virtual machines to isolate each and every piece of third party garbage out there, but that's a real pain in the arse for people like me who create systems which involve multiple pieces of hardware/software using different CPUs, languages and so on and so forth...

[sigh] I guess I'm going to have to spend some time studying the more arcane details of make utilities and makefiles so I can debug this mess. It's a study I've been putting this off for quite some time. Far too many makefiles are childishly overcomplicated and seemingly designed by immature programmers who admire complex solutions to simple problems - baroque stupidity for the terminally anally retarded.

Christ, I sometimes wonder what it is about so many programmers that makes them incapable of grasping the fact that simple solutions are to be prefererred to complex ones, but such wondering's clearly a waste of time. The answer is, as it so often is, merely stupidity.

Grump, snarl.


After a lot of farting about I sort of cured the makefile problem... What I don't understand is what brought it on. The cure was to replace a couple of absolute paths with relative paths.

Like this:

BASE_DIR = c:\foo\bah\sdk
BASE_DIR = ..\..\foo\bah\sdk

Now, the thing I don't understand is what changed on the machine to stop the first version working. The paths haven't changed, the relative paths just refer to the same directories as the static paths did. The static path makefiles still work on other machines, they used to work on this one, FFS, and without anything changing now they just don't. There are times when I hate computers...


  1. Shitty programmers believe that complex solutions are better because they offer better "bragging rights" about how cool (overcomplicated) the solution was. Compare the success of the hateful Webcomic "xkcd" which is based entirely on bragging about things one doesn't understand, or recently looked up on Wikipedia, in order to sound clever.

  2. Surprised that the LINUX hoards arnt blaming the fact that you are using windows (despite the fact that 90% of Linux nerds cant actually code in the 1st palce)

  3. But is it me using windows or windows using me?