[Haskell-cafe] How to install HOpenGL to Windows?
duncan.coutts at worc.ox.ac.uk
Thu Apr 30 19:13:51 EDT 2009
On Thu, 2009-04-30 at 23:31 +0100, Claus Reinke wrote:
> > 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.
> "Windows users" - that's a lot of different people to generalize over.
Yes, I was generalising. There are those users who are prepared, even
happy to install cygwin, and there's everyone else.
> >From what I've heard, most complaints are about assumptions made
> by non-windows users that turn out not to hold on windows,
> causing things to fail on windows. Which seems reason enough for
> failure reports, otherwise known as "complaints".
> 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".
> If someone mixes up GCC's standard layout, they need to adjust
> "everything" for those changes, and when that turns out to be rather
> difficult, it is no surprise if GCC seems unable to pick the right
> include or library paths. This particular issue has just recently been
> fixed in GHC head, I understand (will that fix cause problems for
> cabal, btw, when the existing path hacks are no longer needed?).
> Apart from causing lots of other path issues (and confusing tools
> like cabal, which tried to compensate by special-case code), this
> complicated the process of installing headers and libraries used
> by FFI bindings, at least for those windows users who didn't build
> their own GHCs, with the help of a full GCC install.
> And so on..
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.
> Listen to the complaints, there is (usually) a real issue behind them.
I don't think the problem is that we've had a messed up mingw.
> 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
> Improving Cabal to replace autoconf is a nice long-term goal,
> but in the meantime, things could be made a lot easier for
> those "windows users". GHC using the standard layout for
> its GCC is one step, packaging up the msys and cygwin
> dependencies would make it straightforward to install those
> correctly (someone with installer knowledge might even
> be able to automate that from the cabal commandline..).
> 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.
> PS. Don't think of "them" and "they" vs "we" and "us"
> and "our software". It doesn't help. Neither does
> classifying bug reports as "complaints".
I'm not complaining about people complaining. :-) I'd like to see things
work better on windows.
More information about the Haskell-Cafe