[Haskell-cafe] Re: Hackage on Linux

[Andrew Coppin]

Erik de Castro Lopo wrote:
> Andrew Coppin wrote:
>
>   
>> On Linux, if I do, say, "cabal install zlib", it falls over and tells me 
>> it can't find the zlib headers. So I go install them, rerun the command, 
>> and it works. On Windows, I issue the same command and it falls over and 
>> says that autoconf doesn't exist. It doesn't even *get* to the part 
>> where it looks for header files!
>>     
>
> You are trying to build code that is designed on and for Linux. As such
> it will probably work on all variants of Linux, Mac OSX and a majority
> of Unix variants (after installation of the required GNU tools).
>
> Unsurprisingly it does work on windows because windows because windows
> does just about everything differently to the Linux and the rest of
> the world does it.
>   

The C zlib library itself works just fine on just about every platform 
I'm aware of (including Windows). What doesn't work is the Haskell 
binding to it. (And even that does work if you can get it to build - 
e.g., IIRC zlib is now in HP.)

>> Interestingly, even though everybody claims that it's "impossible" to 
>> support C bindings on Windows, gtk2hs has managed it somehow.
>>     
>
> The reason that works is probably because whoever released it had
> a windows machine available and took the time to make it work.
>
> In general, code written on and for Linux/Unix is not going compile
> with little problem on most Unix-style OSes and close to zero chance
> of compiling without siginficant work on windows.
>   

Much like the chance of OSS written for Windows working under Unix 
without a lot of work. (Yes, people write OSS for Windows too.)

> The problems I claim windows has with respect to compiling and
> installing FOSS:
>
>   a) No standard place to find C include files.
>   b) No standard place to find libraries.
>   c) No standard way to find if common open source libraries are
>      installed and where.
>   

As best as I can tell, the Unix Standard Way(tm) to do this kind of 
thing is to put files into "well known" locations so that they can be 
easily found. (The fact that tools like autoconf need to exist tells you 
something about how tricky this can be.) The Windows Standard Way(tm) is 
to install your stuff wherever you like, and then record its location in 
the Registry. Generally this applies more to run-time resources; I'll 
grant you that compile-time resources are more tricky. I think the 
expectation is that you'll use some kind of IDE, configure it to say 
where the header files and so forth are, and it will generate the 
appropriate command strings to build and link everything.

For whatever reason, developers not native to Windows tend to avoid the 
Registry, so libraries ported to Windows (rather than native to it) tend 
not to register themselves in the Registry. So that's still perhaps not 
much help here.

Regardless, you'd think Cabal could provide some way to make it "easy" 
to state where the files it needs actually are. Currently it does not.

>   d) Missing common unix tools like bash. awk, sed, grep, make,
>      autoconf, automake, libtool, pkg-config etc.
>   

If all you're trying to do is compile some Haskell files that include a 
few C headers, arguably you couldn't need any of these things (except 
perhaps for discovering where your files are). If you were trying to 
build the underlying C library itself... well *that* is another task 
entirely. C tends to be highly non-portable. Fortunately, most 
interesting C libraries have already been ported by some kind soul; it's 
just a question of building the Haskell bindings.

> Ideally for installing open source libraries the tools used should be
> the same as the ones used on Linux/Unix where they originated.
>   

Not all open source libraries originate on Unix. Some of them are 
actually native to Windows. But anyway, that's tangental to this 
discussion...

>> My "obviously all desktops are Windows" was not meant to be entirely 
>> serious. But it's not exactly a revelation to state that Windows has 
>> much greater penetration in the desktop market than either Linux or 
>> indeed Mac OS.
>>     
>
> Your assessment is valid for user desktops but highly questionable
> for developer desktops.
>   

I can go along with that.