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

[Duncan Coutts]

On Mon, 2009-04-27 at 19:03 +0200, Sven Panne wrote:
> 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.

Right. It's still possible to use custom code in Setup.hs to test these
kinds of things. It's a bit less easy however.

> 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.

I didn't know that there was any working GHC for Cygwin. Or do you mean
building a non-cygwin lib but under the cygwin shell?

> > >    * 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.

Right, there's just the includes that come with ghc's bundled version of
mingw. Cabal knows how to find them because they're listed as an include
dir for the rts package I think.

> 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...

But you have some way of finding them right? Even if it's platform
dependent. We can do the same in the .cabal file or the Setup.hs.
There's also a Cabal flag users can pass to tell us about extra lib and
include dirs.

> 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.

Absolutely, finding headers is important. Cabal now checks at configure
time that all header files and libs listed in the .cabal file can
actually be found.

> > >    * 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?

One suggestion I've seen is just to improve the ffi pre-processors. The
c2hs tool is in a position to discover if the calling convention is
stdcall or ccall so it could generate the foreign imports correctly.

> > >    * 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.

Honestly, I've not resolved in my mind which approach is better yet. I
can see the advantages of the feature tests over static per-platform
configurations. On the other hand, declaring packages dependencies (in
as much detail as necessary) has great advantages too in terms of
automating package management. I'm still looking for a solution that
combines the advantages of both.

In practise I've not found that most configure scripts actually do
feature based tests. There's some, but half of it degenerates into "if
we've not got the OSX framework for this then do that". I mean they just
end up doing platform-specific conditionals.

In the mean time I expect we get a reasonable solution by moving as far
as possible the tests into the .cabal and Setup.hs scripts. That would
make building on Windows a good deal less painful and it'll let us see
clearly what we can provide in Cabal to simplify the Setup.hs scripts.

>  * 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.

Cabal does now support the common simple case of checking that libs and
headers are found (when they're declared in the .cabal file). The types
one is probably better dealt with by an FFI preprocessor or possibly
just using the FFI libs directly (sizeOf function), but perhaps could be
done with help from Cabal.

Anyway, so that's why I'd like us to look in detail at what features we
need in Cabal to let us switch most packages from using ./configure
scripts to using Setup.hs scripts.

Duncan