On Sun, 2008-11-23 at 12:30 +0000, Claus Reinke wrote:
It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy.
$ cabal install OpenGL
Nice except that:
1. The command cabal requires cabal-install package to be installed, is it already bundled with all GHC 6.10.1 distributions?
It will be bundled in the Haskell platform installer (as will OpenGL).
When is that going to be available? It would be nice to know that this unfortunate gap period will end within a few weeks or so, especially since interest in Haskell OpenGL has been picking up again lately.
The plan is for the next few weeks. But it'll be done sooner if we can get help, especially from people with access to Windows machines.
In the mean time here's a binary:
The last time I tried bootstrapping from that, I didn't get very far, nor have there been any suggestions on what to do about it:
http://www.haskell.org/pipermail/cabal-devel/2008-November/004168.html
Sorry I missed that email, let me reply now:
The first thing I noticed is that cabal.exe is somewhat stingy about providing information: there doesn't seem to be a "query" or "info" command and, usually, the only way to get information is to look at the "-v" output of doing something (where is the config file? cabal --help should point to it; what are the dependencies for a given package? we can only ask what cabal --install --dry-run -v is going to do with the dependencies; where do packages get unpacked temporarily, for building?..). Querying should be supported, not just doing. Am I missing something?
The cabal list command produces things like: $ cabal list opengl * OpenGL Latest version available: 2.2.1.1 Latest version installed: 2.2.1.1 Homepage: http://www.haskell.org/HOpenGL/ Category: Graphics Synopsis: A binding for the OpenGL graphics system License: BSD3 It does not list dependencies. The config file is in $HOME/.cabal/config on unix and under the per-user applications and settings directroy on Windows. This is the path returned by getAppUserDataDirectory "cabal". It's true it doesn't mention this location very often, just the first time you run cabal, when it tells you that it's making a default config file at the given location. Packages get unpacked in a subdirectory of the temp directory. What extra querying would you like? Please file feature requests with the details.
Having found the config file by looking at the -v output of cabal update.., I tried to enable documentation and to change every path so that cabal would use D: instead of C: (often crowded). That seemed to work, only that I missed that installs seem to be global by default, not user (also, build logs still end up on C:)?
Yes. People complained when I set the default on windows to be per-user installs. If the windows users can argue it out and come up with a consensus then we can change the defaults again. The location of the build logs should be configurable but currently is not.
(btw, I get lots of warnings about deprecated -ffi)
This is very tricky to solve without breaking backwards compatibility for ghc-6.4.
Then I tried cabal install cabal-install (ghc-6.11.20081004, cygwin), and failed.
1. cabal.exe prefers network-2.2.0.0 (installed) over network-2.2.0.1, and building that fails with a Data.Generics issue (wasn't that why the version number was bumped in the first place? and why is it built when it is installed?)
I believe this is now fixed. The ghc-6.10.0.x pre-releases came with a version of network marked as 2.2.0.0 that had different dependencies from the network-2.2.0.0 on hackage. This is what caused cabal-install to think it needed to re-install network. Of course the old version on hackage had not been updated for ghc-6.10 so it failed.
2. trying cabal install network explicitly does install network.2.2.0.1..
Yes. And I as I understand it, ghc-6.10.1 comes with that version. If not it's a packaging bug.
3. cabal install cabal-install still fails, see below
From the build log you pasted it looks like something is wrong with your network package.
Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it).
The problem is that this places an additional barrier on distribution: Haskell OpenGL authors cannot simply distribute their Haskell code, because many other Haskellers will not be able to get it to work:
if they are on Windows:
For the rest of the issues I think the proper solution is the platform installer which would include cabal.exe and a pre-built OpenGL. We could probably do better for packages that need mingw. Most of them record this information in the build-type: Configure, so perhaps cabal.exe should check if sh.exe is present before trying to build packages that need it. If that sounds sensible then lets file a ticket so we don't forget. Duncan