[Haskell-cafe] How to install HOpenGL to Windows?
Sven Panne
Sven.Panne at aedion.de
Mon Apr 27 13:03:16 EDT 2009
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.
More information about the Haskell-Cafe
mailing list