I decided to go with the Eclipse editor since I already knew it from Java, and since it is cross platform. As build environment i chose CMake since I already knew that from previous projects, and I knew it would be able to generate Eclipse and Visual Studio project files for me. As my versioning control system I use Mercurial since the guys at http://bitbucket.org delivers a brilliant free hosting service. To sum up, my development tool chain is the following:

* Macbook Pro, 2011, ATI Radeon 6750M 1GB VRAM
* OSX Lion
* OpenCL 1.1 (since Lion, with Leopard it is 1.0)
* Mercurial version control, using MacHg
* Eclipse CDT, version 3.6.2, 32 bit version
* GDB debugger 6.3.5  (Apple Version)
* llvm-gcc compiler
* CMake 2.8.4 (http://www.cmake.org/)
* CLBuilder for testing kernels

Eclipse CDT has gotten far during the last previous years, and I have been using this editor a lot on the Windows platform. However, on OSX I fairly quickly ran into trouble. Mainly due to crashes, and Eclipse suddenly hanging. After searching the web for a solution I finally managed to find a solution. Disabling the JIT compiler when launching Eclipse. This slows down Eclipse considerable during compilation, but is a necessary evil unless you want to restart eclipse every 1 hour or so!

Disabling JIT
* Go to where you installed your Eclipse.app
* Context click it, and click on “Show Package Contents”
* Find the eclipse.ini
* Edit it, and insert the line “-Xint”
* Save and restart Eclipse.

Also look here: http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.50%2Fdiag%2Ftools%2Fjitpd_disable.html for more info on disabling the JIT compiler.

For now my setup was working fine. CMake was able to generate my eclipse project files by using the -G command when generating my build tree. Now to setup a debugging environment inside Eclipse I had to add a few changes to the CMake Eclipse generator, for choosing the correct binary parser, and error parser for your eclipse project.
By default CMake 2.8.4 generates Eclipse project using wrong the old GNU Make Error Parser 6.0 (deprecated), and the binary parser Mach-O Parser (deprecated) for the eclipse project settings. This will not work when starting the GDB debugging session in eclipse. Changing the error parser to GNU Make Error Parser 7.0 and the binary parser to Mach-O 64 Parser in the project settings manually fixes the problem. However, every time you edit your CMakeLists.txt files, the project settings are reverted!
To avoid this, I patched the CMake Eclipse generator.

Patching CMake 2.8.5
* Open cmExtraEclipseCDT4Generator.cxx
* find “org.eclipse.cdt.core.MachO” and change it to “org.eclipse.cdt.core.MachO64″
* find “org.eclipse.cdt.core.MakeErrorParser” and change it to “org.eclipse.cdt.core.GmakeErrorParser”

Compile and install the patched CMake.

Now you will be able to compile 64bit binaries, and debug them using the GDB build by Apple on the system.

I was and I still is, facing some issues. Such as:

• Unable to set breakpoints in constructors. Probably due to multiple breakpoints set by GDB which cannot be handled by the Eclipse fronted.
• Problems debugging OpenCL kernels properly. You need to use the CLI of GDB to get this working properly.
• Using OSX frameworks and their header files seems to break code completion from these frameworks. Seems to be due to the include path of <OpenGL/gl.h> which the indexer in Eclipse does not seem to understand.

That’s it for now. Next update will probably be some screenshots or videos from the fluid simulator I am developing.

Coming from a Windows platform, there was a few changes I needed to get used too. First of all, no need to install special graphic card drivers, or SDK runtimes to get the OpenCL libraries and includes. On OSX they are all included directly on the platform.

On my machine, running Mac OS X 10.6.7, the OpenCL include files and libraries are located in: /System/Library/Frameworks/OpenCL.framework

To include OpenCL headers in your source code, you need some different includes than that on a Windows system. To be honest I never really understood how the includes on OS X are resolved, but anyway, they need to take the following form:

#if defined(__APPLE__) || defined(MACOSX)

#define __NO_STD_VECTOR

#include <OpenCL/cl.h>

#else

#include <Windows.h>

#define __NO_STD_VECTOR

#include <CL/cl.h>

#endif

The Windows version is included in the above code snippet for completion purposes and ensure cross platform code.

Using GCC on OS X you specify which framework to link too by adding the gcc linker option “-framework”. So to use the OpenCL framework, you need to add the option “-framework OpenCL” when compiling with GCC. This will automatically link the OpenCL libraries, and add the include libraries to the search path when compiling and linking. On OS X other c++ compilers exists, such as llvm-gcc and clang. I will write about my experiences with these compilers in later posts, however the I believe the options for these compilers are the same as when using GCC.

So far my prefered IDE for programming on OSX have been Eclipse. With that I can target both Android application, and native c++ and opencl development projects. Allthought it seems Xcode is a close contender with regard to c++, I prefer to stick with one IDE.

Using Eclipse on OSX proved to be a bit of a hazzle. It kept crashing. After hours of searching forums, I finally figured out that it was due to a reported bug in Eclipse. Disabling the JIT compiler will help, or installing the 32 bit version of Eclipse.

Here is how to disable JIT compiler in Eclipse:

• Open Finder, and go to your eclipse installation folder
• Find Eclipse.app and context click it, and choose “Show Package Contents”
• Go to Contents->MacOS and open eclipse.ini
• Add the following line “-Xint”
• Volia! no more crashes or deadlock of Eclipse.

Using this fix however seems to degrade performance of Eclipse, but for me it is better than a crash.

Downgrading to the 32 bit version is a better choice if you want the performance.