Noobs guide to Linux C++ toolset?

[20thCenturyBoy]

I'm faced with the task of porting my game to Linux. The problem is I get terrified once I leave the comfy armchair of Visual Studio. My experience of C++ on Linux is cryptic makefiles, bizarre g++ errors, crazy library dependencies, and of course...having to use vim or emacs :mad:

Does anyone have any tips about importing a Vis Studio project into Linux as a makefile? Also g++ seems to be a lot more picky than VC++, it's an eyeopener to see your code that compiles cleanly on Windows produce errors (not just warnings!) on g++. Rather annoying though.

Is there a noobs guide to any of this? The thought of makefiles fills me with dread. I last used one in 1989. And you still need to use a tab instead of spaces. What to do?

[roussec]

Don't know if that is the best tip you'll get but IDE wise, give Code::Blocks (http://www.codeblocks.org) a try. Make sure to grab one of the latest nightly builds.

[GBGames]

I don't know of any VS-to-Makefile tools or guides, but as for editors, there are IDEs like Code::Blocks, Eclipse, and KDevelop available. They might help with editing as well as building your projects. You may also want to look into SlickEdit, but it costs money. It does offer a plugin for Eclipse, which may be less expensive.

As for the strictness of g++, also keep in mind that the implementations can be different from one compiler to another. I ran into a problem porting physics code from Win32 to Gnu/Linux, and the problem was the implementation of std::map. On Win32, it allows you to have non-const iterators, but on Gnu/Linux, non-const iterators to std::map are implemented as const.

And both of those methods are perfectly valid according to the C++ Standard. I found a portable and safe workaround in the book Effective STL, though.

What do you mean by "crazy library dependencies"? I've only recently started dealing with library dependencies, and I'm learning a lot, but nothing seems particularly crazy about it. Then again, maybe I don't know what the library dependencies are like on Windows either.

On another note, you don't need to use Makefiles. There are other tools available, such as Ant and CMake.

Good luck!

[GolfHacker]

Perfect timing for your question!

I've written a series of articles on Linux game development, and I received word from GameDev.net this morning that these articles will start running soon (one per month). The first article in the series is in the queue to be published, and it addresses development tools, libraries, and other basic information to get you started developing C/C++ games on Linux.

Keep checking GameDev.net - it should show up soon.

[20thCenturyBoy]

Keep checking GameDev.net - it should show up soon.

Cool - I'll keep an eye out for it!

I tried Eclipse/CDT on Linux but I'm finding it unintuitive. I couldn't even get Hello World to compile. It moaned about main() being an undefined reference. Now I know this is due to some linker issue but for the life of me I couldn't track it down in all the Eclipse menus. It's this sort of thing that wears me out.

[Bad Sector]

Eclipse and other IDEs expect from you to have GCC and G++ installed, including the development packages (f.e. glibc-dev, SDL-dev, etc). They don't do it by themselves (the only thing that Eclipse does by itself is to compile Java code because it includes a compiler, but that's all it does).

Try to read the docs and follow the guide on setting up the CDT. Eclipse was written more with Java in mind and less with C/C++. Not that it's bad - it's one of my favourite IDEs for both Java and C/C++.

Another IDE you may want to try though, is Anjuta. It's a very good IDE and reminds me a lot of Visual C++'s IDE (although it's a lot simpler).

[XIX]

VC project files don't convert well between different versions of VC, so getting them into working nix makefiles may be a bit optimistic. :)

Personally I'd recommend CMake as a way of getting a makefile and a VC project from a master description. It is also a way of not having to maintain VC6 and VC7+ etc projects in parallel.

CMake is a little bit icky but it does the job and works well with VC.

My suggestion is

Step 1: try switching to cmake as a master build system.

Step 2: get a makefile build system working, still on windows, but using MSYS / MinGW.

Step 3: Then try under nix, (KDevelop seems a good IDE to me so check that out).

That way you can have most gcc code issues sorted before you enter the foreign land.

Hope that helps :)

[KatieL]

"Also g++ seems to be a lot more picky than VC++, it's an eyeopener to see your code that compiles cleanly on Windows produce errors (not just warnings!) on g++. Rather annoying though."

It's not as annoying as not being able to build code which built using the compiler the machine had on it yesterday because someone's upgraded from "4-point-builds-it" to "4-point-doesn't" completely passing the "4-point-complains-about-it-but-does-it"..

To be fair, I haven't come across a single instance in which the compiler hasn't been well within its rights under Stroustrup to refuse the code.


You used to be able to provoke VS into producing a makefile for you which might get you started using make if you can find the magic button.

[Bad Sector]

Code that doesn't compile with GCC is code that is either badly written or use compiler-specific extensions. GCC has excellent standards support, at least when it comes to C and C++. If you write code that uses Visual C++, or Intel C++ or even GCC extensions (and GCC provides a lot of extensions... GNU C is far from C - nested functions and dynamic runtime arrays come to mind), you can't expect all compilers to be able to compile your code.

EDIT: an example from my personal experience. I used to do this thing alog:

(struct Foo*)boo = barInstance;

however this is wrong. GCC 2.x and -i think- 3.x was okay with that and it worked in most compilers. However in late 3.x or 4.x the maintainers said that "no! this is wrong, the standard says that we can't do that" (or something else, possibly like that, but i think that they had better reasons :-)) and the above code, although worked in previous GCC versions, didn't worked in later (and i think that's still the case).

But who was to blame? GCC, for removing a non-standard feature or me who used the non-standard feature. Well, i didn't knew that it was a non-standard feature, i just assumed that since it worked, it was ok. Since GCC had a ground, i think that i was to blame. Besides writing standards compliant code isn't bad.

And isn't like there isn't a correct way to do the above. Just move the typecast at the other side:

[code]
boo = (BooType*)barInstance;
[code]

[20thCenturyBoy]

Thanks for all your replies. I'll look into cmake. I actually tried kdevelop and it seems ok in a kind of half-assed way. I'll try Anjuta as well.

Code that doesn't compile with GCC is code that is either badly written or use compiler-specific extensions

Yep, more than likely :D

One of the bits where it complains is when I use C std library constants like FLT_EPSILON. G++ complains about it not being in a scope. I tried using ::FLT_EPSILON but it still complains. I'm including <cmath> and <limits>. Compiles ok under VC++. Any ideas?

[Bad Sector]

FLT_EPSILON and DBL_EPSILON are defined in limits.h. In C++ you use std::numeric_limits<float>::epsilon() and std::numeric_limits<double>::epsilon().

Talk about language bloatness...

EDIT: In Visual C++ it may work because the C library may include limits.h from <limits>.