From: Andrew Coppin
John Lato wrote:
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...)
Indeed, in theory it would work this way. In practice, not so much.
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?
AFAIK, this is true to an extent. I think that someone like Duncan could explain the role of Cabal better than I can. Of course Cabal was missing much of the necessary functionality until only recently. As an example, the possibility of listing C library dependencies was only added in 1.6 IIRC.
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. :-}
Agreed (by users I presume you mean Haskell developers). I remember that many readers of this list were shocked by the download numbers for the HP, particularly the high number of Windows downloads. I think it goes to show that there is interest among Windows developers, as long as they have the sense that their platform is equally-supported compared to Linux. There are many more potential windows developers than linux developers due to the size of the Windows install base, so good Windows support is one of the easiest ways to expand the audience.
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.
I don't mean that Windows needs to become just like Unix. I mean that if Windows supported a common installation location for .dll's and .h files (and binary packages regularly provided them), much of this difficulty would be easily resolved. It wouldn't be "becoming like Unix", it would mean adopting to a C distribution model that Unix happens to share. Regardless, I think I have a better chance of winning the lottery jackpot than seeing MS support this in my lifetime.
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.
This goes back to the catch-22 you listed above, but I wouldn't say Windows support is "without any problem." First you need active Windows developers for this. Commercial products have a big advantage here. Second, Windows support means a host of platform-specific bugs to be dealt with in every part of the package. These are in addition to any other bugs that you'd have anyway. FWIW, I had great difficulty in building hCsound on Windows, and my primary development box at the time was WinXP. I did eventually make it work with the binary csound distribution, but not without a lot of pain derived from the specifics of the binaries in ways that cabal can't (and probably shouldn't) be expected to handle. John