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

[Sven Panne]

Am Mittwoch, 29. April 2009 11:25:31 schrieb Duncan Coutts:
> On Mon, 2009-04-27 at 19:03 +0200, Sven Panne wrote:
> > [...]
> > 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.

That's why the autoconf macros are so tricky. Re-inventing the wheel in 
Haskell is not something I'd like to do. Note: I see autoconf as a necessary 
evil, not as a glorious tool. The predefined autoconf macros contain man years 
(if not man decades) of sweat and tears from people trying to make their SW 
portable. If you only know 1 or 2 platforms, everything looks easy, but this 
is not the case at all. Good luck for everybody trying to ignore that 
accumulated knowledge...

> 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? [...]

I don't know if GHC currently builds under Cygwin, but in former times it was 
*the* way (read: one and only way) to build it on Windows.

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

I even have standard, well-documented, platform-independent way: Tell 
configure about it via the environment variable CPPFLAGS for headers and 
LDFLAGS for libraries. Cabal is buggy in this respect, IIRC, it passes no or 
incorrectly named variables to configure.

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

I don't know what Cabal does internally, but simply checking for the existence 
of a header file or a library file is *far* too naive, look into the autoconf 
docs and/or mailing lists to see why. You actually have to compile for header 
checks and link for library checks, everything else is plainly wrong, because 
you'll probably miss dependencies, pick up the wrong stuff, etc.

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

This wouldn't help much: The foreign imports in OpenGL are written by hand, 
and when the OpenGL ARB ever manages to release some consistent, machine-
usable and complete API description (the current .spec files fail in almost 
all these aspects), they will be generated from that, not from C headers, 
because, not surprisingly, the latter lack a lot of information.

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

This is often correct for hobby projects of inexperienced people, but not 
necessarily for larger or more mature projects. And in a (very) few cases, 
platform-specific conditionals are even the right thing to do, but not in the 
vast majority of cases, of course.

And this has nothing to say about autoconf itself: Seeing e.g. ugly Haskell 
code is not a reason to condemn Haskell itself, either.

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

As I said in another email: I'll happily review and accept patches for this, 
but I won't spend any effort on re-inventing the autoconf wheel in Haskell.

Cheers,
   S.