Sunday, June 14, 2009

Signals, Paths, and Static Libraries on the Mac

The last few days I have been thinking about and designing out the engine for the game. As I stated before, all this time I have been writing tests apps and using programmer art and some art the artist of the game prepared to make sure all the mechanics of what I wanted to do worked.

So, now the design is clearer in my mind and ready to get built. One thing I know I wanted in the game is a messaging system. So, instead of writing my own observer/listener and visitor patterns to handle it, I decided I would use, "Boost::Signals." So, I went about putting together a small test to make sure they could work. I include the header "boost/signals.hpp" in my file, set the path to the include and libraries in my project settings and copied in the signals .a library file into my project. I coded up my sample, after fixing some syntax compile errors I built it and all cleared compilation and linking. Next step, fire that baby off. BOOM! Crash!

Okay...what's going on. I step through the debugger and I could see that the code was crashing on the "connect," call of the signal (note: if you are curious and don't know about Boost::signals read up at boost.org, I will not be giving a tutorial on them here). Now, I really have fallen in love with developing on the Mac, but it still has some shortcomings, one of which is XCode. The flaky breakpoints, and sometimes not remembering my changes, I can live with, but the very generic error messages are a real pain. Armed with only sigbus(10) error. I scowered the internet. I found that my problem was a stack overflow. Documents recommended that the Boost:signals library be recompiled on the target machine.

After hours recompiling, re-downloading the library and recompiling and still getting the error. I was at my wits end. So, for grins I said, let me grab the 1.39, latest Boost build. Well, I found in the deliverable notes that "Signals2," had been added to the library and it didn't use a library, just a header file that had everything inlined, which screamed to me, "NO REBUILDING OF THE LIBRARY!" I liked that, scream at me all you want (holla atcha boy).

I think most good programmers, are lazy programmers, so we build tools to do the work for us. My laziness goes even further, I like the tools I'm going to use to already be built for me as well. So, I placed the paths to the new library in my project settings and rebuilt. Sccreechh!

The boost include path couldn't be found. Which leads another pet peeve with the Mac. Since I'm not a unix guy, I wish things like setting environment variables were easier. Noooo! If you read a blog entry of mine long ago, this entry seems like deja vu, because I remembered I had this same problem when installing Boost the first time I wanted to see if it would work in the iPhone environment. I searched back to that blog posting to see how I did all this before.

I found in order to do so I would have to get a terminal window and use the "bash," shell and set the path. So, I followed my earlier blog's instructions and promptly set the boost path, but blew away my other paths. Which rendered "ls," inoperable, leaving me having to type out, "/usr/bin/ls," each time.

So, I turned to a friend, Everett Harris, who is a unix/linux guy (Ohh...I know some unix/linux guys too, is he...no he isn't some pudgy, pasty skinned guy, with long hair, a beard, and wearing suspenders). He instructed me that the easiest way to add/append to the path is (okay, I'm documenting it right here so the next time I forget, I will know how to do it correctly) type the following...

PATH=$PATH=/your path here
export PATH

That's it. So, armed with that knowledge I set my path, and reset all the paths I had blown away. Changed over to "signals2," rebuilt everything, ran it, and viola, my little test now works. Yes, yes, "the journey is, the reward." Sheesh!

So, now back to engine design. I'm laying out all the data, actions, and messages, so I know how I want to hook up all the components, and then I will start coding. Probably, by mid week I will begin coding, at that point I should just be in my zone, knowing what and how I wish to do things...when I am at the point, things tend to go much faster.

No comments: