OS X compile fixes

[fommil]

some basic work for #7.

There is a also a bunch of system setup that needs to be done... but that is best worked around with hackery at the moment because it involves changing so much code (specifically the location of the cl.h file is not under CL/cl.h, it's in the frameworks directory, malloc.h is in malloc/malloc.h and I have no idea what the OS X #define logic is looking for... you should be looking for MACH)

sudo port install boost gcc-4.8
mkdir build
cd build
ln -s /System/Library/Frameworks/OpenCL.framework/Headers/ ../src/include/CL
ln -s /usr/include/malloc/malloc.h ../src/include/malloc.h
#CC=gcc-mp-4.8 CXX=g++-mp-4.8 LDFLAGS="-framework OpenCL" cmake ../src
LDFLAGS="-framework OpenCL" cmake ../src
make

[fommil]

@kknox ! PING

[kknox]

@fommil I am working on this; I do not have access to Mac machines at my workplace, so I am resorting to borrowing my wife's laptop at home to make progress on this, but i can only work on it at nights and I don't work on it every day. If I integrate this code as is, it breaks on users machines because the OpenCL detection logic doesn't work. I won't merge the pull request like this.

I am applying cmake-fu to the cmake detection logic, but my OSX-fu is poor. These framework bundles are new to me and I have to do a lot of reading right now. As of today, cmake can detect the dylibs fine, but for whatever reason it fails to find the header files.

[fommil]

@kknox yeah, I've never found a satisfactory solution to header file inclusion using the -framework approach. Seems to know about the libs, but not the include path.

To compile on OS X with this PR needs the symbolic links in the comments. You'll see that it is an incredibly repetitious process to change all the CL/cl.h => the preprocessor version.

[kknox]

I saw your comments about the symbolic links in the comments and they have been helpful for me, thank you. However, i have to assume that people who clone the repository will not read this thread and I want it to work 'out of the box' for them.

[fommil]

oh cool, I thought you meant it was still breaking for you. Yeah, the intention is that your cmake skillz replace the symbolic links. Thanks!

[kknox]

Ok, i have cmake logic correctly detecting OpenCL, but in my opinion this is not a complete solution. The problem is that the frameworks in /System/Library/Frameworks/ do not appear to have header files installed in them (I checked in OpenCL, OpenAL, OpenGL framework directories), at least on my wife's Macbook. She has OSX10.8. I then installed Xcode on my wifes laptop through the app store, and that appears to install a complete OpenCL framework in this location: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/OpenCL.framework This directory has the combined headers and dylibs, and I can get cmake to correctly configure itself to use this.
I'm not entirely happy with this because this creates a dependency on xcode, and I'm not convinced that we need one.
Can anyone enlighten me why I might be missing headers in /System/Library/Frameworks/, and how might I be able to install them there? Is there some equivalent to apt-get or zypper or yum?

[fommil]

@kknox interesting, I thought the headers were there by default and, at the very least, in the expected place after an xcode install. This sounds like a very recent change in process from Apple.

I believe xcode is always going to be a dependency. I don't know how you did any dev without it! It is needed to use macports or fink, or homebrew etc.

[kknox]

We should count on xcode always being installed for developers; this is a safe and understood assumption? I've managed to develop without xcode by only developing on windows and linux before.

[fommil]

@kknox I think it's a sane assumption that any OS X devs will have XCode installed... even if it's only to bootstrap a macports or other environment.

[abergeron]

It appears I should have checked the pull requests in progress before making my own.

For the headers issue, Frameworks work quite a bit differently than traditional packages, the headers are in .../OpenCL.framework/Headers/, but they are not prefixed by the traditional CL directory.

The official way to fix this is to use <OpenCL/cl.h> rather than <CL/cl.h> on OS X machines, which is what I did in my PR.

Although, this is all on 10.7 and Apple may have decided to remove the headers from the system frameworks in 10.8.

Also, for the clock issue, I believe my solution is better since the time source I use is not subject to NTP adjustments.

[kknox]

The official way to fix this is to use rather than on OS X machines, which is what I did in my PR.

Hi abergeron, I didn't understand what you said in your comment; how did you get the build to work on OSX? I did not see cmake changes in your pull request.

[abergeron]

I did not have to do any changes to the CMake logic to get it to add "-framework OpenCL" to the link command.

As for the includes I changed every location that includes <CL/cl.h> to <OpenCL/cl.h> (conditional on APPLE being defined).

However my machine is on 10.7 and I have seen mention that there are no headers in the 10.8 framework. Could you give my version a try just to see if it builds.

Edit: I just realized (again) that github deletes everything between < and > if they are not properly escaped and my comment does not make a lot of sense that way. I've also edited my comment above with proper escapes.