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

[Claus Reinke]

>> If someone wants to use a unix shell on an unknown platform, they 
>> should at least check that one exists there or -even better- provide 
>> one, not just assume that there'll always be one (and then be surprised 
>> about getting complaints from "those windows users"). Same for
>> autoconf, make & co.
> 
> You mean that we should be shipping a haskell platform with a full copy
> of mingw + all the tools to make configure scripts run? I doubt that'll
> make people happy. They'll complain about it not being "native".

The platform includes GHC, which already includes mingw (GCC)!-)

What I meant was a cabal package bundling the pieces of msys (sh,
autoconf, make,..). And, no, the haskell platform doesn't need this,
so it should be a separate package. But cabal install should know
that this package would be nice to have at hand if building a package
that uses build-type:configure on windows.
 
>>just fixed:
>> http://hackage.haskell.org/trac/ghc/ticket/1502#comment:12
> In principle there is no problem with finding the mingw headers on
> Windows. All we need is that the rts or base package specify them in the
> include-dirs in the package registration info. Cabal uses the same info.

In practice, we have instructions like these circulating (these being
examples of the better kind, as they actually got things working):
http://joelhough.com/blog/2008/04/14/haskell-and-freeglut-at-last/
http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/

And I've lost count of the number of times the finding of mingw
headers or libs has caused bugs (which usually went unnoticed
on the author's machine because the author would have a full
copy of mingw in c:/mingw, where gcc looks for things when
everything else fails - oh, unless you're using ghc's gcc on d:,
when this failsafe would suddenly fail as well, until recently).

Perhaps cabal had no problems with this, but problems were plenty
and initially non-obvious. So I'm happy that this fix has eliminated one
common cause of problems with installing Haskell software on windows.
Every little bit helps.
 
>> A couple more examples of why installing the tools that some 
>> cabal packages rely on isn't straightforward: 
> 
> But there is a significant number of Windows users who do not care to
> install these tools at all.
> 
> Making the stuff work better for people who choose to use cygwin is
> great. I have no objections to that. But the majority want "stuff" to
> work without them having to install cygwin. In this case "stuff" often
> means random hackage packages and many of them are using configure
> scripts.

If cabal can do autoconf/configure stuff without having autoconf/
configure installed, great. Someone could write SH as a Haskell 
DSEL, for starters, then replicate the autoconf stuff (its all just SH
libraries and some macro processing, right?). But I'm not optimistic 
about that in general.

There probably are windows users who don't want to have
msys or cygwin on their machine, but I suspect there are more
windows users who simply don't want to bother with msys (so
if cabal installed and used it internally, they might accept that,
just as they accept, or at least live with, GHC installing and 
using mingw internally).

>> Then windows users could easily install either msys or
>> cygwin, and the remaining issue would be how to install
>> the headers and libraries for cabal packages with ffi 
>> bindings. Just as on other platforms.
> 
> Making them easier to install would probably convince many 
> Windows users to install one of them.

It would also simplify cabal package installation instructions,
and avoid the "it doesn't work and it thinks it is on unix so I
don't see how it could possibly work" feeling. Instead, cabal
install would simply point out another package dependency
that needs installing.
 
> I'm not complaining about people complaining. :-) I'd like to see 
> things work better on windows.

I'm not surprised!-)
Claus