John Lato wrote:
To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either.
Agreed.
While it is Cabal's job to find the location of necessary libraries, header files, and tools, there simply is no feasible way to do so on Windows without searching most of the hard drive.
Also agreed.
The only workable approach is to have users specify the locations of these files, which unfortunately requires more sophistication than can be expected of most Windows users (and even some Windows developers).
Well, I don't know. It's going to vary from package to package, but most things that have a semi-official Windows version either come as a Windows Installer package (which, one presumes records where it put everything *somewhere* in the Windows registry), or possibly the *developer* package comes as a simple Zip file that you just unzip to wherever you fancy. Just tell the user the URL to grab the Zip file from, unzip it and tell Cabal where the root is now. Shouldn't be too hard. (Famous last words...)
The problem, of course, is that, especially if the file layout differs significantly in the Windows version of the library, this is going to absolutely _require_ somebody with a real Windows box and familiarity with Windows to work on the Cabal packaging. (In extreme cases you might even end up needing a completely seperate, Windows-only Cabal file.) Presumably nobody will ever have the time or inclination to construct this.
On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on "configure". These packages will continue to require cygwin or mingw for the "configure" step.
Ah yes, this is pretty much guaranteed to make stuff not work on Windows. :-) Still, all Unix systems have Automake, configure, etc., so I guess most people don't even think twice before using it.
I gather it's supposed to be Cabal's job to figure this stuff out in Haskell land?
One last wrinkle: many distributors of C libraries do not have Windows machines available to test, and (understandably) have little interest in supporting a platform they don't have and aren't familiar with. As a result, many C libraries are not well supported on Windows and require somebody familiar with gnu build tools (i.e. gcc, make, and autoconf) to be usable on Windows *at all*. This means that, as a Haskell developer wanting to use these libs, you need to use gnu build tools because you're not just binding to the library, you're maintaining a Windows port of it.
This seems to be kind of the catch-22. Nobody uses Windows, so there isn't much support for Windows, so we don't attract many Windows users... QED. :-}
C and unix are pretty much designed to work together, and have been for decades, so I think it's reasonable to expect that Windows is the side that needs to adapt to support their model.
In other words, "Windows needs to become just like Unix". Not going to happen. ;-) Argue about whether this is good or bad amoungst yourselves. But it's not happening.
MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows.
I don't know about that... Lots of commercial and open-source products are available for Windows and Unix, seemingly without any problem. (GTK, for example...) I don't deny that adding Windows support is _a lot more work_ than adding support for just another Unix, though.
Cross-platform support precludes windows-native solutions, so you're left making the best of it with Linux tools (mingw and cygwin) on Windows.
Yeah, it seems for the time being any Haskellers wanting to work on Windows have to choose either to not use external C libraries or to install the entire GNU toolchain. *sigh*
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
