source release and linux porting

This topic is 2472 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I made a game in windows with Code::Blocks. It works pretty well, but a problem turned up when my friend wanted to play it on Linux (Ubuntu). Since my game relies only on cross platform libraries, I figured it would be really easily to compile, but it was not to be. Despite spending all afternoon, he was unable to get it working.

How do people manage cross platform releases?
Here are the issues I've seen.

* Lack of Code::Blocks. I have been using Code::Blocks for all my development, but my friend didn't have it.
Apparently, the usual method is to just provide the source files and a makefile, but I have no idea how to create a makefile. What should I do, besides just telling people to get C::B?

* Lack of required libraries. My game relies on SDL, SDL_Image, etc. Box2d, Boost Filesystem, and a modified version of SDL_Mixer which in turn relies on the various Vorbis libraries, etc.
Also, even in cases where the correct libraries are present, they are usually in different places. On my computer, I have all the libraries in specific places, but this will differ from person to person. Is there any way to get the build process to figure stuff like this out?

* Incompatible library versions. For example, my game currently uses a version of Box2d that is a couple revisions behind head. I guess the only way to deal with this is to just tell people which revision to use?

* Library placement. On Windows, I can just distribute the exe and all the dlls required in the same folder without interfering with anything else. I assume Linux does things differently, but I have no idea how it works.

* Different UI expectations. On Windows, I pop up a message box when an error occurs with the Winapi. However, from what I can tell, Linux programs are expected to write errors to either stdout or stderr. Is this correct? I'm a little worried that users will never see the error if the program isn't invoked from the terminal, and will have no idea what went wrong.

Share on other sites
[quote name='Storyyeller' timestamp='1302656258' post='4797730']
I made a game in windows with Code::Blocks. It works pretty well, but a problem turned up when my friend wanted to play it on Linux (Ubuntu). Since my game relies only on cross platform libraries, I figured it would be really easily to compile, but it was not to be. Despite spending all afternoon, he was unable to get it working.

How do people manage cross platform releases?
Here are the issues I've seen.

* Lack of Code::Blocks. I have been using Code::Blocks for all my development, but my friend didn't have it.
[/quote]
Tell him to install it. Code::Blocks works fine on Ubuntu. He can use the ubuntu software center, or apt-get to quickly install it.

[quote]
Apparently, the usual method is to just provide the source files and a makefile, but I have no idea how to create a makefile. What should I do, besides just telling people to get C::B?
[/quote]
Yes, the "usual" method is GNU autotools, or another build system. I suggest CMake as it is fairly easy to setup, and runs on both windows and linux. AND since it is designed to spit out project files it can create makefiles, C::B projects, Visual studio projects, etc. So people will be able to build using whatever tools they have available.

[quote]
* Lack of required libraries. My game relies on SDL, SDL_Image, etc. Box2d, Boost Filesystem, and a modified version of SDL_Mixer which in turn relies on the various Vorbis libraries, etc.
Also, even in cases where the correct libraries are present, they are usually in different places. On my computer, I have all the libraries in specific places, but this will differ from person to person. Is there any way to get the build process to figure stuff like this out?
* Library placement. On Windows, I can just distribute the exe and all the dlls required in the same folder without interfering with anything else. I assume Linux does things differently, but I have no idea how it works.
[/quote]
Installing librarires is stupid easy on linux. They all boil down a command like:
sudo apt-get install libsdl1.2-dev libboost1.3.6-dev

You just need to make a list of the libraries you need, and he should be able to quickly find the packages and install them.

Linux puts all the libraries in specific places, like /usr/local/lib and /user/local/include. Thankfully all the relevant software also knows this and will go searching there when you compile and run your programs. You don't have to configure locations for anything, as they all go to specific spots.

Usually you'll want to have the end user install the runtime shared libraries for the packages you need, so "libsdl1.2" instead of "libsdl1.2-dev"( dev libraries come with includes, static libraries, and runtimes). This is because they don't need all that source code if they don't have to build your project.

[quote]
* Incompatible library versions. For example, my game currently uses a version of Box2d that is a couple revisions behind head. I guess the only way to deal with this is to just tell people which revision to use?
[/quote]
Hopefully they didn't break their API in the upgrade, but the apt repository on linux usually has a couple releases in it to choose from. Usually the more problematic issue is that the repositories are updated on a schedule based on tested releases. This means that some fast moving libraries like SFML aren't going to be up to date, and you'll have to download and build from source. (usually build from source is easy. Most big library packages try to keep things simple by using autotools, cmake, or another build system that amounts to only one or two simple commands).

[quote]
* Different UI expectations. On Windows, I pop up a message box when an error occurs with the Winapi. However, from what I can tell, Linux programs are expected to write errors to either stdout or stderr. Is this correct? I'm a little worried that users will never see the error if the program isn't invoked from the terminal, and will have no idea what went wrong.
[/quote]
Yes, it seems quite standard to just dump everything to the console. You can still make popups for your errors if you want, but requiring user input (hit ok to continue) isn't a good way to report errors. I personally hate that windows apps do that because you can get a message box part way though a graphics init, and then the message box may not have focus, and is hidden behind your app's fullscreen window. thanks, now i have to fumble around to try and kill your app with an invisible task man, or just reboot.

You also have to consider that remote running applications on linux is trivial in most cases, and you're app will need a fallback if it can't use the window manager. I can ssh from my laptop to my PC and run most gui apps with the interface on my laptop while the app runs on my PC. (its like remote desktop on windows) But if i forget to apply X-forwarding on my ssh connection then the app is going to fail and have to print a console error "can't connect to X window server" to remind me to remake the connection. Probably not an issue for games, cause OpenGL doesn't forward well. But something to think about for any other apps you may have made.

Share on other sites
[quote name='Storyyeller' timestamp='1302656258' post='4797730']
* Different UI expectations. On Windows, I pop up a message box when an error occurs with the Winapi. However, from what I can tell, Linux programs are expected to write errors to either stdout or stderr. Is this correct? I'm a little worried that users will never see the error if the program isn't invoked from the terminal, and will have no idea what went wrong.
[/quote]

No. It's more that some workflows are easier using the command line. But as your game is graphical, it makes sense to notify the user with a message box (just make the text copy/paste-able if you want users to be able to report errors).

Edit: not necessarily a true message box with its potentials problems, but some graphical notification.

Share on other sites
Makefiles on *nix often use pkg-config to discover the libraries and flags required to use some library, something along the lines of:

[code]
CXXFLAGS:=$(shell pkg-config sdl SDL_mixer SDL_image --cflags) LDFLAGS:=$(shell pkg-config sdl SDL_mixer SDL_image --libs) -lboost_filesystem -lBox2D

my_prog: $(foreach FILE,$(wildcard *.cpp),$(FILE:%.cpp=%.o)) (CXX)$^ $(LDFLAGS) -o$@
#^ Make sure this is a tab, spaces will break the Makefile.

%.o: %.cpp
(CXX) -c $<$(CXXFLAGS) -o \$@
#^ Same here.
[/code]

Libraries that don't use pkg-config, sometimes install a [i]<library-name>[/i]-config script you can use for the same purpose, and sometimes all you need is a simple '-l[i]<library-name>[/i]'.