Disclaimer: Warning – code rant ahead

Okay, I’m still tinkering with the Torque engine and trying to figure out the best way to integrate it with our framework project. My first instinct was to define the engine as a big black box – seperate from the main code – so that it was easy to define what is ‘Torque bits’ and what is ‘Assault bits’. Easy enough you’d think – just put it in a subdirectory and wrap it up as a static library.

Bear in mind the Torque engine comes as a big demo project, with all of the code to do anything you like in a big source tree, and nicely it works just straight out of the box. Nice and easy to use, but I feel a bit dirty when I’m hacking other people’s applications to look more like I want mine to look; its good for learning purposes, but once I’m done I like building something clean from scratch which references the engine rather than modifies it.

So the engine-as-a-library approach is nice and clean – it fences the engine code off as ‘something to be used’ and gives the project a bit of modularity. But, and here’s the kicker, its really simple to split Torque off as a library, but the first thing the linker does when it finds that library is it strips out anything it doesn’t think is used; including several vital parts, because it can’t tell that they aren’t used until runtime. When it’s a big monolithic executable project, the compiler just assumes they will be used (otherwise they wouldn’t be in the project), but as a library it tries to be (too) smart. Grrr.

Okay, so I go to the Torque search engine to see if its come up before, and it has – like every 6 months, since 2002. The response is invariably along the lines of either a) “I like a big executable, it keeps everything together”, b) “If it ain’t broke, don’t fix it”, c) “Yeah, we’re thinking about doing that some
time soon, honest”, or d) “why don’t you do it yourself, and we’ll consider putting it in”. I won’t go into why these are poor responses, but I’d say that if its been that way for 3 years, its likely to stay that way.

Anyway, it looks like the hack and slash of the big demo source is the only way to make it work. Maybe I’m just being too picky, but we’re at that nice initial stage of the project where you want to keep things clean and well laid out, because you know its going to go downhill over time. Last thing any developer wants is to have to tell new people on the team – “yeah, we know its bad, but we’re stuck with it now”.

This entry was posted on Thursday, May 12th, 2005 at 11:08 am and is filed under Tales from the grind-stone. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.