[Haskell-cafe] How to install HOpenGL to Windows?

[Sven Panne]

Am Montag, 27. April 2009 00:11:20 schrieb Duncan Coutts:
> On Sun, 2009-04-26 at 19:03 +0200, Sven Panne wrote:
> [...]
> >    * How to link programs using OpenGL
>
> This is because the GL libs are called different names on different
> platforms right? But they're consistent within each platform, it's just
> Windows vs everyone else isn't it?
>
> How about:
>
> if os(windows)
>   extra-libraries: gl32
> else
>   extra-libraries: GL

As usual, things are always a bit trickier than they appear initially: On non-
Windows systems it is not always sufficient to link against libGL alone, 
sometimes you'll have to link against several X11 libs, too. I am not sure if 
this is still a widespread problem, but in the past it was. Hopefully most 
*nices get their dynamic library dependencies right nowadays... :-P Windows 
is, as always, a special beast, especially when you take Cygwin into account: 
On Cygwin you can either build against the native OpenGL or against Cygwin's 
X11 OpenGL. This can be configure via --without-x. How can we do this in 
.cabal files? And MacOS had some peculiarities which I can't fully remember 
anymore, too.

> >    * The Haskell types corresponding to the OpenGL types
>
> Does hsc2hs #type not help us with this? [...]

I am not sure, because I haven't had a look at hsc2hs for a long time, and at 
the beginning of the OpenGL binding there were no such tools, not even the FFI 
in its current form. Perhaps I'll have a look at this, but to make this work, 
I am sure that we'll have to solve the next item:


> >    * To do the former: How to find the OpenGL C headers
>
> What's needed here? Are they not in standard locations? Cabal has
> support for users to specify non-standard locations.

What is a "standard location" for headers on Windows? There is no such 
concept. On *nices you look into /usr/include and /usr/local/include, and 
that's it, unless the user tells you something different. And Apple is always 
a very creative company, so they decided to put *their* OpenGL headers in a 
completely different path where no -I flag can help...

Having access to the OpenGL headers is crucial for finding out which C types 
are behind OpenGL types like GLint, GLenum, ... The OpenGL spec only specifies 
minimum requirements for these types and *not* their C mapping.

> >    * The library calling convention
>
> This is stdcall on Windows and ccall everywhere else right?
>
> How about:
>
> if os(windows)
>   cpp-options: -DCALLCONV=stdcall
> else
>   cpp-options: -DCALLCONV=ccall

This should be fine, at least when we solve the Cygwin problem discussed 
above: The X11 OpenGL libraries on Windows do *not* use stdcall, only the 
native OpenGL libraries. (The whole calling convention story on Windows 
really, really sucks, IMHO...) Using CPP for this simple task doesn't look 
right, but with the current FFI I don't see a way around this, which is a 
shame. Any ideas/proposals for a FFI change?

> >    * How to load OpenGL extensions
>
> I don't know enough of the details here to comment.

You'll have to know if wglGetProcAddress, NSAddressOfSymbol (+ a bit more 
code) or some variant of glXGetProcAddress has to be used, plus their 
necessary headers. This is probably doable via some platform switches in 
Cabal, too.

A few general remarks:

 * Ignoring the (usual) Windows trouble, I like autoconf's approach of testing 
features instead of relying on extremely fragile platform conditionals. The 
latter are a constant source of troubles and from a SW engineering point of 
view, they are a clear step backwards. The "I know my platform" approach which 
you basically propose reminds me of the xmkmf hell from the last millennium: 
If X11 didn't know your platform, you had a *lot* of fun getting the platform 
description right.

 * We can go this autoconf-free route, but this is a part of my bindings which 
I definitely won't maintain in full time. I'll be happy to review and accept 
patches, but making things work on Windows, Cygwin, Linux, *BSD, MacOS X, ... 
is a lot of work, which is a fact I have painfully learned in the past few 
years. The autoconf code may be ugly, but the tons of platform differences are 
ugly, to. I want to work on the binding itself mainly, not on the build 
system, which currently works. To repeat myself: Patches are happily accepted, 
but I propose incremental changes and heavy testing on various platforms.

 * Most of the tasks my autoconf scripts perform are not specific to OpenGL at 
all. I guess that most bindings for non-trivial C libraries face the same 
challenges (Where are my libs? Where are my headers? What are my types?) 
Having good Cabal support for these would be very nice.

Cheers,
   S.