> From: Andrew Coppin <andrewcoppin(a)btinternet.com>
>
> 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
