Thursday, February 21, 2013

Adventures in Porting to a Mac


I have switched my main computing platform to OSX, and this past weekend I decided to try to move my development workflow over from my windows machine. I figured this should be easy enough considering my whole development stack is open source: Eclipse, GCC, OpenGL, and CVS. As always things are never as simple as they should be.

Current Environment
  • Windows 7 64bit
  • MinGW GCC 4.7 32bit
  • Eclipse (Juno)
  • Source code in CVS
At first, I thought I should just convert my project to XCode. Right off the bat, it shoots down with its lack of CVS support. Not a big deal, I think, I will just use my old standby: Eclipse. Thwarted again; XCode doesn't share it's compilers by default. I have to download the command line tools package. Apple's servers are slow and the 500mb download took over an hour.

Back in Eclipse, I check out my code and hit compile. There were major errors with all my C++11 code. I double-check my compiler parameters and everything is correct. What is this? GCC is version 4.2. It looks like Apple is betting the farm on Clang (not a particularly bad bet IMO) and has left GCC to wither on the vine. I guess I will just have to update my build to use Clang.

I check the Eclipse marketplace and sure enough, there is an LLVM/Clang plugin with experimental OSX support. After installing I have the same issue: the XCode version of Clang comes preconfigured to use GCC4.2 headers. I dig up the requisite compile parameters "-std=c++11 -stdlib=libc++". With that out of the way I start the build and find hundreds of errors. It seems that Clang is much less lenient than GCC; particularly with error checking unused inline functions (GCC doesn't bother in some cases). I also have a problem with missing libraries. Apple’s OpenGL and GLUT libraries use Apple’s framework system. I had to replace my “–l” link parameters with “-framework”. One nice thing about the framework system is that with one parameter it sets the include paths, library paths, and library dependency.

Time for the link and then boom, the Eclipse plugin requires the LLVM linker (llvm-ld), which is no longer included in the version included with XCode. When I enter the project properties to fix this, I get a null pointer exception from the LLVM plugin. Experimental Indeed. It looks like this will have to wait for another day. Fortunately some fine people on the internet build an OSX version of GCC 4.8 (available here) Installation is as easy as unzipping and changing the GCC symlinks in /usr/bin to point to the new version. This build also supports the –framework parameters so things are still good.

After I build with the latest GCC compiler, I get an OpenGL runtime error: my shaders failed to link. When I dig in to diagnose, I notice that my delete key stopped working along with a few other keyboard commands. Eclipse has its own internal key mapping system with some known issues.
This same issue is probably the reason why my OS level custom keyboard commands do not work in Eclipse. (I set up OSX to use home/end like Windows/Linux).

For the sake of making progress, I fire up Eclipse in a Windows 7 VM running Parallels 8 (which supports 3d acceleration pass through) to see if the shader linking issues persist. They do. NVIDIA’s shader compiler on windows is helpfully/notoriously lenient on syntax, but the OSX compiler likes to stick it to you. Thankfully all it took to fix was a version tag at the beginning "#version 120". The spec says to use version 110 if it is missing, and that just was not new enough for my shaders. Everything works again in Windows. I check back in OSX and after a quick build in eclipse everything works great.

From here, I am not sure how to proceed. It would be nice if Eclipse worked as well on OSX as it does in Windows and Linux. Will Eclipse's Clang plugin work on OSX before Apple drops GCC support completely (slated for the next release of XCode)? Perhaps I should make separate project files in XCode. I would like to target the iPhone eventually, this may be inevitable. Alternatively, I could just finish the game on one platform first and then worry about the porting issues later. Eclipse for Windows runs great in a VM. For the time being, I think I will stick with that.