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.
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.
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?).
http://hackage.haskell.org/trac/ghc/ticket/1502#comment:12
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..
Listen to the complaints, there is (usually) a real issue behind them.
A couple more examples of why installing the tools that some
cabal packages rely on isn't straightforward:
I like and use cygwin, but when installing it, one has to be careful to
include all the bits that are needed, preferably leaving out the bits that
might cause confusion when used for GHC/Cabal (such as a second
GCC installation). I once tried to capture the list of dependencies
needed for building GHC in a cygwin pseudo-package (no contents,
only dependencies), which made that easy.
http://www.haskell.org/pipermail/cvs-ghc/2005-May/025089.html
http://hackage.haskell.org/trac/ghc/wiki/Building/Windows/Cygwin
But then cygwin's installer added security signatures, and I don't
think such were ever added to the pseudo-package, the dependencies
are also not uptodate anymore (I don't have write access to where it
was put). Nowadays, one could put the cygwin pseudo-package into
a cabal package on hackage, including the necessary signature, and
that cabal package could run the cygwin installer with the dependencies
given in the cygwin package (assuming there's a commandline interface
to the cygwin installer) or at least users could run the cygwin installers
with an updated version of that cygwin package, and get a cygwin
setup useable for cabal packages.
Others like msys, but for some reason the msys developers hardly
ever put up a simple installer, one usually has to collect various
bits and pieces in the right version, then unpack them on top of
each other - very far from automated one-click installation. Simon
recently collected the pieces needed for building GHC, so one
could now point windows users to
http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
for "one-stop shopping". One could probably do better by
collecting those pieces into a cabal package (assuming the
license is favourable), but I could never find documentation
for using the mingw/msys installers from the commandline,
as a cabal package would need to do. Someone familiar
with those installers might not find this difficult.
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.
Claus
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".
-- It is not that we think of "other" as bad,
-- it is that we think of bad as "other".
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
