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".