[Haskell-cafe] Re: binding to C libraries on Windoww
andrewcoppin at btinternet.com
Mon Dec 7 17:00:53 EST 2009
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.
> 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.
> 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"
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
> 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
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*
More information about the Haskell-Cafe