Wrapping up libtcod, swig, and cmake nonsense soon hopefully....

While I've enjoyed the libtcod, swig, and cmake work, my interest is seriously starting to wind down. Here's a status update:

libtcod-java - See this mailing list post. Nobody has answered yet, and I have no clue how to get it working right now. This might have to be stowed.

libtcod-php - Waiting to hear back from person who wanted it to see if they wanted php4 or php5. cmake apparently only support php4 naively.

libtcod-ruby - Apparently there is some interest in this, but it isn't working for them. Will be trying to sort that out.

libtcod-cmake-osx - Working with somebody via e-mail (slowly) in order to try to get this working.

libtcod-csharp - Working with somebody via e-mail to sort out crashes and problems I'm not seeing.

Bit of libtcod swig isn't wrapping - Heightmap is down to four functions not being wrapped. BSP looks like a bit of a lost cause. The SWIG documentation on function pointers and callbacks is almost unreadable. The only way I can figure to wrap it is to remove the callback, and create functions that return lists of all the nodes in the BSP in the requested order.

Bringing cmake to libtcod - Last bits of polish

(Your regularly scheduled blog posting about c# and magecrawl will return shorting, this is the last post scheduled to deal with cmake and libtcod.)

The last major issues I believe have been worked out. With the exception of osx support, which libtcod didn't have up to date in the first place, and some documentation I'm planning on writing tonight, cmake support is finished.

I finished up upx support last night, and spent today breaking up the build files into libtcod and sample parts, which makes everything much more clear. Overall, despite my gripes last night about its documentation, cmake is a great build system. It is vastly better in my opinion than makefiles, and the only build system is comparable in features is scons.

If you're writing a roguelike (or anything really) in C/C++, and consider cross platform important at all, I'd take a look at cmake.

Bringing cmake to libtcod - Why "use the source Luke" doesn't mean you can skip documentation..

I'm going to start this quick post off by saying that cmake doesn't have the worst documentation ever. I'd generally award that honor to the C# swig documentation.

However, the documentation for cmake leaves much to be desired. Throughout my work, I've found most of my help with Google and other peoples submitted scripts. I'm going to try not to be cynical and assume that this is due to them selling a book.

Anyway, it seems that the upx for cmake documentation just doesn't exist. I can find nobody on the internet using it. *Edit* I found one person here but it isn't working for me. At this point, I'm digging into the source of FindSelfPackers trying to figure out what I need to tickle to get it working. While this is better than the situation if cmake was closed source, it saddens me nevertheless.

(/endrant)

As the maintainer of libtcod-net, which is only somewhat documented, I realize this same complaint could be leveled back at me. If you happen to find yourself cursing the documentation of libtcod-net, please let me know.

*Edit-2* Since apparently I have a high google rating for "upx cmake" and I've found my solution, I'll post it for any future googlers. I gave up on using the built in finder, and am just using the one visible from the prompt. I'll have to variable it out to work on windows, but it's "good enough".

samples_c being the name of one of the outputs:
        ADD_CUSTOM_COMMAND(
            TARGET samples_c
            POST_BUILD
            COMMAND upx samples_c   
            VERBATIM
        )

Bringing cmake to libtcod - Almost there...

From my original list:

• Build the example programs
• Add back opengl support
• Test linux (and mac if I can get ahold of one) builds.
• Seperate C and CPP libraries for linux.
• Install build stuff to root directory
• A list of nice to have.
• Documentation! Quickstart guide!
• Work on issues provided by and try to convince maintainers of libtcod that cmake is better.

Ignoring the mac build, which I still don't have, I only have the "nice things to have" (upx, electric fence), documentation, and some cleaning up to do.

CMakeLists.txt is now 160 163 lines of text so far. Compared to 1209 lines of makefiles it's doing the job of, its currently 7 1/2 times shorter. It is also one place to update the new/deleted files, as opposed to 8 makefiles + a codeblocks project that exists somewhere.

Assuming upx and friends don't take forever, I'm figuring one more good afternoon is all it will take to get a passable build done.

Update: Scratch electric fence, it was a 3 liner over breakfast.

Bringing cmake to libtcod - And then there was Linux

Since my last post I've accomplished a few things. One of them includes:

The sample programs were ridiculously easy to move to cmake. Almost one liners in fact.

Beyond that, opengl has been added back. That was pretty easy, find_package has to be the coolest macro in cmake.

Linux support happened this morning. Other than some bashisms in my script to generate the cmake files, all it took was a few more find_packages to use the system headers/libraries.

Last thing of note was a quickstart document was written up, to get people started using cmake if they want to try it out. On libtcod's SVN head, its cmake/QuickStart.txt

Still a lot to do, but I'm getting there.

Bringing cmake to libtcod - First Successes

I just checked in cmake files that will build libtcod and libtcod-gui under both visual studio and msys/mingw.

I still have a laundry list of things to do left including:

• Build the example programs
• Add back opengl support
• Test linux (and mac if I can get ahold of one) builds.
• Seperate C and CPP libraries for linux.
• Install build stuff to root directory
• A list of nice to have.
• Documentation! Quickstart guide!
• Work on issues provided by and try to convince maintainers of libtcod that cmake is better.

But I am happy with what I've accomplished so far.