Built on Linux

[ktvoelker]

EDIT: Using this patch is no longer recommended. Instead, get the official source from Bitbucket and build using the Boost build system.

After trying out Goblin Camp I was very excited to start helping with development. But I am more of a Linux person, so I thought I would try to get it built on Linux. It was an adventure that consumed my entire evening, but it's now built and seems to work!

Here is a patch. It contains a few minor tweaks to the code, and a makefile. The makefile contains some notes about steps which need to be taken prior to building Goblin Camp. If you run into any issues using the patch, please feel free to ask. I'm not sure how good my embedded instructions are.

In general, I found that I had to download very recent versions of GC's dependencies in order for everything to build correctly. It would be very helpful to know exactly what versions of the various libraries are being used for the Windows build.

The patch currently contains some whitespace-mangling accidents resulting from my editor's use of spaces (in place of tabs) and Unix newlines. I will get that stuff cleaned up soon.

Of all the changes to the code, only one is really notable: in class Entity, I made the X and Y functions non-virtual. None of the descendants of Entity appear to override X or Y currently, so this works for now. The reason for doing this is a bug in G++ which causes the Boost Serialization stuff to break. What I have yet to figure out is why all the other virtual functions in Entity are not causing a problem. But, they don't, which is good enough for now. The Boost bug tracker doesn't have a link to a G++ bug report, so I'm not sure if the Boost people ever reported this across or not. I'll try to figure that out when I have time.

[gencontain]

Great stuff! I added a dependency sticky that has the versions that I use, should've remembered to add that earlier.

Can I link to this post from the front page? Theres probably other people too who'll appreciate a linux version.

[ktvoelker]

Go ahead!

[dirtywizard]

Nice work. It's good to see a linux version already.

I was planning to try compiling under linux but after looking at your patch file, I'm fairly sure I would have given up. I'll try this out when I get home.

[ktvoelker]

gencontain: are you interested in putting Linux support into the official repository? And, what kind of Linux binary distribution do you want to do? Packages for popular distros? A generic package with the necessary libraries included?

For now, my patch is available via a fork on bitbucket. I will try to keep up-to-date with new mainline patches.

https://bitbucket.org/ktvoelker/goblin-camp-linux

Current priorities:

1. Make building on Linux a bit more sane.
2. Make a binary distribution of some kind.

[gencontain]

I suppose linux support could be built into the official repo, but then again a fork works just as well I'd think? If there's a good argument for not having it in it's own fork do tell me.

I'm no linux expert, but I'd think that getting binaries out for the most popular distros would be a good idea. I'd expect that people running more esoteric linux variants will also be fine with compiling GC. But really, I'll leave it to your judgment as to what kind of packages you want to make.

[ktvoelker]

It would be really helpful to keep the core source code in sync between the Windows and Linux versions. Otherwise, every time there are new patches on the Windows versions, all the little differences that have piled up in the Linux version are going to make merging into a big headache.

But it's probably still good to have a separate Linux repo, so that if a patch goes onto the mainline which breaks Linux, it's not going to be distributed to every Linux user who built from source and does a pull. So basically, it would be nice to keep the repos in sync, except when there's a Linux compatibility problem being worked on.

Currently, my changes to the source code are:

* Fixing the capitalization of #includes
* Replacing uses of std::string::pop_back (which the GNU STL doesn't have)....but I just realized that it would be better to provide a Linux.cpp which simply implements std::string::pop_back. I'll work on that.
* Making Entity::Y and Entity::X non-virtual.
* Hiding the Windows main function with #ifdef WINDOWS (I was just guessing about using "WINDOWS"...is there some defined variable that indicates the compilation is happening on Windows or with MSVC++ or something? Or, if not, can you add one?)

I am still concerned about the bizarre g++ bug I mentioned earlier. I had to make Entity::Y non-virtual to get around the bug. If that change doesn't make it back into the mainline, and you end up relying on the virtualness of Entity::Y later, then the Linux version will be pretty much doomed. (Which is to say that the Boost serialization would have to be replaced with something completely different in the Linux version. But unless the serialization is replaced across the board, save files aren't going to be compatible between OS's, which would be bad.)

Really, this g++ bug is making me want to get rid of the Boost serialization right now and replace it with something else. But that's a bit premature. Once I have investigated the problem more fully, I may be able to come up with some coding guidelines to ensure that serialization on Linux doesn't break again.

[gencontain]

Actually I have no reason at the moment in keeping Entity::X() and Entity::Y() virtual, and I think I already changed that. If I didn't, I will. Only Position() needs to be virtual.

I'm pretty sure theres a variable that indicates it's being built in MSVC, I'll look into it and start using it to #define out the windows stuff as necessary. It shouldn't take much to make the main repo platform independent.

Boost::serialization has given me a bunch of headaches as well, it took me ages to get it to compile and work properly. Not really the best documented library, but now that it does work it's pretty nice. But even then I had to put all the save/load stuff into the same file because of god knows what issues, and I couldn't spare any more time in figuring it out. I hate template related errors, the amount of lines it generates is immense.

If you figure out a better way than boost::serialization then be my guest and implement it.

edit: I'll fix those header capitalization issues as well. Seems that changing ides 3 times has left problems in the code. MSVC++ thankfully capitalizes header files correctly for me, so that problem shouldn't show up again.

[clockfort]

* Hiding the Windows main function with #ifdef WINDOWS (I was just guessing about using "WINDOWS"...is there some defined variable that indicates the compilation is happening on Windows or with MSVC++ or something? Or, if not, can you add one?)

You want "#ifdef _WIN32", Karl.

--Clockfort

[antagonist]

Just a note:

If platform portability is important I would advise switching to a make system like cmake(cross-platform make).

Yes, it wont help you with having to #ifdef out the stuff, but it allows most common formats of project files to be generated from the same sources: VS2008, VS2010, codeblocks, unix style makefiles, xcode projects for mac...

One of the biggest issues I've had with my own projects when not using cmake is that you have a project file for VS(possibly multiple of them, for 2003, 2008, 2010), a codeblocks one, a makefile, all of which needs to be updated if even a single source file needs to be added.

It also has some other nice features, like ability to find dependancies in most common directories on all platforms, optional compilation, filling in configuration h files, ability to create unit test and install projects.

http://www.cmake.org/cmake/help/cmake_tutorial.html

Thats a quick tutorial, and an introduction to some of what it does.

</plug>

Anyway, great work. Hope to see this continue!


EDIT:
Personally I wouldn't worry about ppl breaking linux on source control occasionally, it will happen. Just need to mark 'releases' that ppl can update to when they want to compile from source. Personally I think that having cross-platform in the official repo is the best way. Just note that windows is the primary supported platform.

As for the windows main function? I havn't looked at the code, but do you mean WinMain kinda stuff? If so I would avoid it like the plague. You're not working with windows GUIs, and libtcod doesn't need it. main(argc, argv) is portable and works well.

EDIT2:
Well, this is better than double(triple?) posting.
If cmake looks good, I can help to port it over. Dont have TOO much free time lately, but this seems a project thats worth some love.