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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe