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

[Duncan Coutts]

On Thu, 2009-04-30 at 19:44 +0200, Sven Panne wrote:

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

The thing is, it doesn't really matter if autoconf macros work fine for
every Unix ever invented. The Windows users simply cannot use packages
with configure scripts. They complain about it a lot. We can call them
foolish for not installing cygwin/mingw, but they will not do it and
instead will simply not use our software and/or continue to complain.

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

Right then lets fix it, lets work out exactly which flags or env vars to
pass. See:
http://hackage.haskell.org/trac/hackage/ticket/458

Doing it is not hard, it's working out exactly what to pass that's the
important matter.

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

Right, that's exactly what it does. We checked used the autoconf macros
as guidance.

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

I don't see that the two approaches are exclusive. For example with Gtk+
we also generate from an incomplete API description with manual
adjustments because of lack of info. However we generate .chs files that
then get processed by c2hs so that we can check if our binding at least
matches the C header files. Certainly the C headers are not enough (no
info about memory management) but the bindings do at least have to be
consistent with the C headers on the current platform. And the C headers
do say if the calling convention is ccall or stdcall (otherwise the C
progs would not work).

But this is not a short term fix, it'd be a complete change for the
binding so I'm not seriously suggesting it.

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

I'm not asking you personally to do that. I'm asking for help from you
or others on identifying the tests that we need to do to support our
most common Haskell bindings packages.

Duncan