dumb down our CPP so that it works in both traditional and ansi modes

[dagit]

This patch looks big and onerous but you really only need to understand the changes in HsOpenGLRaw.h. Everything else is just an automatic change that could be done with sed (I used vim macros) to add the two new parameters to EXTENSION_ENTRY everywhere it's used.

I tested the changes on:

• OSX Mavericks
  • 7.6.3 from homebrew, uses gcc instead of clang for CPP
  • 7.8.2 built from source, uses clang instead of gcc (previously failed with a parse error)
• Windows 7 64bit with 7.8.2 64bit.
• Linux + lots of ghc versions via travis-ci, details: https://travis-ci.org/dagit/OpenGLRaw/builds/24942160

While this change is not optimal, I think it's a reasonable compromise that lets us fix #18 and #21.

[svenpanne]

I don't think that the CL is completely correct: We need another argument for the stringification of _entry, otherwise all error messages will be wrong.

[mchakravarty]

@dagit How about the probably simpler solution I proposed in the comment of #21? (In any case, thanks for taking care of this!)

[dagit]

@mchakravarty I couldn't get the -pgmP stuff to work. More details here: http://www.reddit.com/r/haskell/comments/25aw7o/solutions_with_respect_to_conditional_compilation/

Briefly:

If we use -optP-ansi it gets ignored (because ghc passes -traditional). If you use your own CPP, via -pgmP cmd, -traditional is not added, but then clang's CPP doesn't take the same arguments as gcc's CPP so you can't just use -pgmP cpp. We could pass -pgmP gcc -optP-E, but then that a) assumes gcc, and b) we don't know if we're getting the same C compiler/version that ghc uses. We could figure that out using Setup.hs, but IMO writing anything in Setup.hs is a nightmare to maintain because you can't specify dependencies for that file. At that point, I'd try cpphs instead.

[mchakravarty]

@dagit Why is it important to use the same CPP as GHC?

Besides, GHC just uses configure's AC_PROG_CPP and then adds -undef -traditional as flags. If it spots clang, it also adds -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs.

So, why not just use AC_PROG_CPP in configure as well and then add -undef and, in case of clang, also -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs to invoke it.

[dagit]

Matching up the CPP versions is not a big deal for our uses here. I imagine it could become unhygienic if you're doing something low-level with FFI details and gcc and clang disagree about library implementations. I think the most likely problem we'd run into is assuming gcc is the name of the C compiler. The user might have gcc-4.7.2 instead and no plain gcc. Or perhaps, they don't have gcc at all and prefer clang?

Does cabal define AC_PROG_CPP? I thought that is part of autoconf (and we're not currently using it). I like to avoid autoconf whenever I can :)

If I could just disable -traditional that would be ideal for this.

Keep in mind, we would like to switch to autogenerating these files from the specification (and someone made a prototype). Once we do that, we could eliminate this part of CPP easily.

[mchakravarty]

Without autoconf, it is harder...

[Laar]

Indeed all complicated parts of the CPP can be done by such a generator (and my prototype does so). Though we would still need CPP for the different calling conventions, which is, fortunately, far more simple that this.

[dagit]

@mchakravarty I was wrong about the CPP version skew. It looks like ghc is using this flag:

       -undef
           Do not predefine any system-specific or GCC-specific macros.  The standard predefined macros remain
           defined.

I think that means it's not actually possible to depend on implementation details and existing #defines.

[mchakravarty]

@dagit Yes, it definitely uses -undef.

[mchakravarty]

Thank you!

[svenpanne]

I've updated the OpenGLRaw, GLURaw and GLUT packages, they should build out of the box on Mac OS X, too. Could somebody please verify this? I've tested things on Linux and Windows, so it would be nice to hear from the Mac side. If everything is fine, I'll release new package versions and try to get these into the upcoming platform.

[mchakravarty]

I grabbed the current repos for all three packages and build them on OS X 10.9 (Mavericks) with GHC 7.8 using Cabal 1.18. Worked without a hitch. Thanks for the update.

[mchakravarty]

I also did a run with GHC 7.6.3 (using my version of the Xcode 5 fix http://justtesting.org/post/64947952690/the-glasgow-haskell-compiler-ghc-on-os-x-10-9). It's also fine.

[schell]

Worked for me on OS X 10.9, GHC 7.8.3 and Cabal 1.20 👍