Swift/Mac: OpenGL.framework when using clang modules

[AE9RB]

Using in a Mac project where clang modules are enabled causes many errors starting with:

/usr/local/include/GL/glew.h:16426:17: error: declaration of 'PFNGLCOPYTEXSUBIMAGE3DPROC' must be imported from module 'OpenGL.GL3' before it is required

Here's what's going on. When GLEW loads glu.h the entire OpenGL.framework PCH is brought in ignoring the #define _gl_h from glew.h meant to prevent this. Things like GL_VERSION_1_2 become defined. So the GLEW typedefs and defines get skipped.

Can the loading of glu be done at the very end? I built a Swift package to wrap GLEW and created a shim that has that effect. Seems to work. Couldn't figure out any other way because there's currently no option to turn off clang modules in Swift (and there may never be).

https://github.com/AE9RB/SwiftCGLEW/blob/master/shim.h

Note that this package is for the newly open source Swift. It enables OpenGL on all platforms. If you want to test SwiftGLEW you'll need a GL context, so here's a binding to GLFW3: https://github.com/AE9RB/SwiftCGLFW3

[nigels-com]

Ideally we'd simply skip glu.h for Swift, as we already do for iOS...
Any suggestions for some preprocessor logic?

#ifndef GLEW_NO_GLU
#  ifdef __APPLE__
#    include <Availability.h>
#    if defined(__IPHONE_OS_VERSION_MIN_REQUIRED)
#      define GLEW_NO_GLU
#    endif
#  endif
#endif

#ifndef GLEW_NO_GLU
/* this is where we can safely include GLU */
#  if defined(__APPLE__) && defined(__MACH__)
#    include <OpenGL/glu.h>
#  else
#    include <GL/glu.h>
#  endif
#endif

[nigels-com]

I'd recommend using -DGLEW_NO_GLU for Swift, for sure.

[AE9RB]

It's not just Swift. It's anything using clang modules on Apple. So everything Xcode too. It probably never came up before since you just "import OpenGL" in Xcode so why bother with GLEW. Which is the answer on Q&A sites.

You can't -D with the open source Swift right now. Really. The Swift package manager is very anemic. I do have GLEW working with glu and I'm hoping new Swift features will let me do something less fragile in the future. But maybe we can fix it up for everyone using modules in other languages too.

The issue is I don't know why glu is loaded so early. I assume for some platform I'm not familiar with. If that's not the case, glu can be moved to the very end of GLEW.h so it's painless everywhere. Or maybe just for Apple it's at the end. Doing Apple at the end works in my tests.

If you don't see a problem with doing Apple at the end, I can send a patch. I can also move all glu to the end. Probably easier to maintain all glu in one place. But not if it blows up some other platform.

[nigels-com]

GLEW itself doesn't need glu.h. It's only there to maintain compatibility with applications that depend on GLU via glew.h. Isn't GLU deprecated on the Mac nowadays?

[nigels-com]

Oh, we're dealing in pre-compiled headers here? Ouch!

[AE9RB]

Ouch indeed. include <OpenGL/glu.h> is converted by clang into import OpenGL.GL.GLU which triggers a full pre-compiled header load of everything in OpenGL. It's all fine if you load glu at the end though.

GLEW has been broken in XCode since version 5 because of this. That's when Apple enabled clang modules.

[nigels-com]

I have not touched XCode much since the clang migration, I guess. GNU make works just fine, of course. :-)

[nigels-com]

Is AE9RB/SwiftCGLEW abandoned at this point? I'm reading up about Swift, especially because there is a Linux version. But I'm still not sure what all the fuss is about.

[AE9RB]

More problems came up the further I progressed. It got to where I had to fully parse gl.xml. At that point it was easy to do everything in Swift with no dependency on C code.
https://github.com/AE9RB/SwiftGL

I don't know what everyone else is doing in Swift. But it seems to me like a good language for 3D programming. Modern syntax. Fast and easy C calls. No indeterminate delays from a GC.

[nigels-com]

At my workplace it's all about Julia, so Swift is probably not going to be on my radar, so much.

[nigels-com]

Nothing further for this, for now.