Tuesday, April 8, 2014

Making Me Crazy

I actually got some stuff done this week! Unfortunately, that 'stuff ' was overhauling my make files, so I don't have much in the way of pretty screenshots to show off. However, it's something I've been wanting to do for a while now and it feels good to get it done. The system is now a lot more modular. For example, the large scale terrain simulation I was working on is now properly separated from the game, whereas before I had to comment/uncomment code just to switch between the two.

I've never actually described my work environment in this blog before, so now seems like a good time to do that. I had to learn how to work in Linux at my last job. Having been spoiled on Windows my entire life, it was a trying experience. However, in time, I learned and got comfortable with it. Eventually, I got to the point where I actually preferred it. Currently, I have Fedora 20 installed on my home computer with the Xfce desktop environment.

I discovered something else during that time. A friend introduced us and it was love at first sight. I am of course talking about Sublime Text, the best text editor on the face of the planet. I tried it out one day and never looked back.
I've been using C++ for just about a decade now. It's actually kind of mind boggling to me that that's true. Needless to say, I'm comfortable with it, and that's what I'm programming my projects in. The compiler I'm using is GCC.
Editing my code on the left with Sublime, compiling it on the right in a transparent terminal, occasionally with a video playing in the background.
One of the biggest problems I've had with my personal projects over the years is that I tend to break them and then forget about them. The result is that I had little to show for all the tinkering I did. To mitigate this, I started using a personal Git repository. Now I can revert to earlier builds and show them off.

That alone wasn't enough though. I have some common code that is shared between projects. All too often, I'd make changes to that common code while working on one project and end up breaking all the others. This would lead to me avoiding those broken projects until they were long forgotten.

The first step I took to fixing this was to clean up my make system. Until now, each project had it's own makefile that was nearly identical to all the other ones. Now I have one common makefile that is used for all my projects (although each project has a small makefile for project-specific settings).

I also created a simple, but good dependency system. Each project can depend on any number of other projects and specify how the code for those projects will be linked to create the final executable. The three options are:
  • Direct Linking - Object files from the dependency are linked directly into the executable.
  • Static Linking - The dependency is built into a static library (.a / .lib).
  • Dynamic Linking - The dependency is built into a shared library (.so / .dll). 
The list of dependencies is recursively expanded, with duplicates and circular dependencies removed. The order is preserved to ensure everything is linked in the correct order.

Build targets are determined by two factors. The mode (debug, release, etc) and the platform, which is a combination of things like OS and architecture. Corresponding preprocessor defines are passed to the compiler for when target-specific code is needed.

The plan for the future is to create a Git branch for each project. This way, I can change the common code used by one project without breaking all the others. I will need to occasionally update projects to reflect changes to the common code, but I'll be able to do this when it's convenient, rather than being forced to do it whenever a change is made.

No comments:

Post a Comment