On 06-05-2015 16:32, Sven Panne wrote:

2015-05-06 16:21 GMT+02:00 Bardur Arantsson :

...

+1, I'll wager that the vast majority of usages are just for version range checks.

The OpenGL-related packages used macros to generate some binding magic (a "foreign import" plus some helper functions for each API entry), not just range checks. I had serious trouble when Apple switched to clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources had been checked in. :-P Nowadays the binding is generated from the OpenGL XML registry file, so this is not an issue anymore.

Ok, so it's *not* a counterexample :).

...

If there are packages that require more, they could just keep using the system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd want to see real evidence that that's actually worth the effort/complication.

Simply relying on the system CPP doesn't work due to the various differences between GCC's CPP and the one from clang, see e.g. https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. Ignoring the problem doesn't make it go away... ;-)

No, but is it worth the effort? (As opposed to workarounds, such as just checking in the preprocessed file as you provided an example of.)

Note that we still need CPP to handle the various calling conventions on the different platforms when the FFI is used, so it's not only range checks, see e.g. https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588.

Certainly. I'm not saying *everybody* just does range checks, but I'm guessing that it's the majority of CPP users are using it just for that. (I'm not going to be doing any of the work, so this is just armchairing, but this seems like an 80/20 solution would be warranted.) Regards,

Sven Panne writes:

2015-05-06 16:21 GMT+02:00 Bardur Arantsson :

...

+1, I'll wager that the vast majority of usages are just for version range checks.

The OpenGL-related packages used macros to generate some binding magic (a "foreign import" plus some helper functions for each API entry), not just range checks.

So, metaprogramming. The question that comes to mind -- why suffer such a lousy tool as cpp for metaprogramming? Why *shouldn't* TH fill that role? What can be done about it? -- regards, Косырев Серёга