[HOpenGL] FYI: Haskell Platform release candidates

[Claus Reinke]

> Exactly. Of course reports about problems and suggestions for improvements are 
> always welcome, but I wouldn't mind reports about working platforms, too. 
> Currently I don't have a clear picture which package works where...

I've installed OpenGL-2.2.1.1 and GLUT-2.1.1.2 with ghc-6.11.20090320,
on windows xp, using cygwin&mingw, though I had to add a configure option:-(

    cabal install opengl --configure-option="--host=i386-unknown-mingw32"
    cabal install glut --configure-option="--host=i386-unknown-mingw32"

(that is with "GLUT for Win32 version 3.7.3 as of October 2nd 2000").

> This raises a point which is a bit unclear, at least for me: Where do users of 
> the HP report a bug? It can be a bit tricky to decide if it's only a packaging 
> bug, which I can't fix, or a real bug in the OpenGL/GLUT binding. Has this 
> been discussed in the "HP inner circle"?

I'm a square, I belong to no circles!-) You'd need to ask on the HP list.

But OpenGL/GLUT don't have a trac instance yet, and I've had little success 
in the past with cc-ing you on issue reports, so having all OpenGL/GLUT 
reports on the HP trac, in a OpenGL/GLUT component, wouldn't be a bad 
start, would it? Of course, you could add an OpenGL/GLUT trac on 
trac.haskell.org:

    http://community.haskell.org/

and then there'd be the question of which trac to use for what.. I'd expect
bugs to be reported on either trac, then forwarded to the other one if
necessary. The same as currently happens with ghc vs hackage/cabal
vs haddock tickets.

> I really, really hope that the minor HP release will allow feature additions 
> where the major version number of the package stays the same. Everything else 
> would bring down distribution of much-wanted features to a crawl and force 
> people to install the packages by hand once again. But again, I don't have a 
> clue what the HP people decided about this...

OpenGL/GLUT is a special case, because it was dropped from extralibs
so long before HP had code associated with it. If not for that gap, the 
time-based HP releases might work (HP is about easy access to stable
reference sets of packages, not about the latest versions). 

So I agree that there should be an exception to the general HP policies 
to get OpenGL/GLUT off to a good start again. But that's just me (I also 
argued against dropping OpenGL/GLUT from extralibs) - if there are only 
one or two people affected, there's no reason for action, and if there are 
more people affected, they should make themselves heard in the appropriate 
forums.

On windows, OpenGL/GLUT does seem to install fairly easily using cabal, 
provided one has msys or cygwin, and glut.. It can only be easier on other
systems, right?-) The problem is that the Haskell binding would allow people
to use OpenGL/GLUT who do not usually dabble in C or msys, so having
a binary tarball (or an uptodate HP installer) helps a lot. Not to mention
users who can't install stuff, let alone msys, on the machines they want
to use for OpenGL/GLUT hacking.

Unfortunately, with OpenGL/GLUT no longer in extralibs, the existing 
machinery for daily binary snapshots of the latest package version (via 
ghc snapshots) is gone, and the hackage server probably can't build 
windows binaries. But someone else could set up a weekly build of
OpenGL/GLUT on a spare windows desktop. Or the situation with
msys or cygwin installation to support cabal install could be cleaned 
up to get rid of this issue once and for all..

The question is how many potential OpenGL/GLUT users are still
affected by this, ie, not served by 'cabal install'?
 
>> Windows installer RC (does *not* include glut32.dll):
>> http://projects.haskell.org/pipermail/haskell-platform/2009-May/000147.html
> 
> Personally I hope this will get fixed for the initial release, otherwise the 
> HP will be only semi-functional out-of-the-box.

If anyone else wants to chime in, the haskell platform mailing list
is the place to go.

Claus