Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD20: How to Lose 40 Minutes During a Ludum Dare Compo

CMake, how I love it when you just work.

CMake, how I hate it when you don’t work.

I should have prepared for this compo by having a basic, buildable project ready to go.

In trying to create the barest project for LD20, I’ve copied the directory structure and CMake build scripts from my LD18 game, which still builds just fine by the way, and changed references from LD18 to LD20.

And for some reason, with a basic main function and a bare-bones Game class that does nothing, I get a build error.

I notice that for some reason, even though I tell it to build the files in my source/game directory, it seems to be ignoring it. It doesn’t ignore it in my LD18 project, though.

First, for posterity (and my sanity), the command to get debug output is “make VERBOSE=1”. I always forget it and have to do searches online to find it, and sometimes CMake searches aren’t easy to do. I need to keep these notes somewhere handy for the future.

Next, I saw that it wasn’t finding my project library. Basically, my game has a main.cpp, and it links to the library created by the game subdirectory. What’s nice about having the game built as a library is that I can also build a test binary if I was using unit tests by linking to that same game library instead of building the object files twice.

After looking at the CMakeLists.txt files and comparing them to the ones in my LD18 project multiple times, I finally saw the culprit:

TARGET_LINK_LIBRARIES (gbgames-ld20-bin gbgamesld20-lib ....

It should link to gbgames-ld20-lib. It was missing a frickin’ dash. Looking closely at the error message, I would have seen the missing dash there as well, but…GAH!

And this is how you lose about 40 minutes during a Ludum Dare compo. B-(

Luckily, I finally got the project building and running, so now I can get some lunch.

1 day, seven and a half hours left. Eat fast.