the true way to install all of hackage is:

cabal install $(all my packages)

where cabal install solves it all.

not really :) e.g. my output on a Windows Vista system with GHC 6.10.1 cabal install sdl Resolving dependencies... Downloading SDL-0.5.4... [1 of 1] Compiling Main ( C:\Users\Peter\AppData\Local\Temp\TMPSDL-0.5.4\SDL-0.5.4\Setup.lhs, C:\Users\Peter \AppData\Local\Temp\TMPSDL-0.5.4\SDL-0.5.4\dist\setup\Main.o ) C:\Users\Peter\AppData\Local\Temp\TMPSDL-0.5.4\SDL-0.5.4\Setup.lhs:2:2: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Linking C:\Users\Peter\AppData\Local\Temp\TMPSDL-0.5.4\SDL-0.5.4\dist\setup\setup.exe ... Warning: defaultUserHooks in Setup script is deprecated. Configuring SDL-0.5.4... setup.exe: sh: runGenProcess: does not exist (No such file or directory) cabal: Error: some packages failed to install: SDL-0.5.4 failed during the configure step. The exception was: exit: ExitFailure 1 To build this I guess I would have to install MinGW and MSYS (which is already insanely hard to unzip all the latest development stuff in the right places and configure it correctly, especially for a windows user), and then do all kinds of tricky things that are obvious for unix people but alien for dummy windows users like me :) Anyway, support for Windows users gets better each year, which is great!

On Sat, 2009-01-31 at 14:02 -0800, Don Stewart wrote:

...

not really :) e.g. my output on a Windows Vista system with GHC 6.10.1 cabal install sdl

...

Configuring SDL-0.5.4... setup.exe: sh: runGenProcess: does not exist (No such file or directory)

Isn't this missing C library dependencies, which cabal head now warns about?

No, it's about packages using configure scripts which require MSYS on Windows. In principle we should be able to notice this while doing the package dependency planning and report that we cannot install the package because it needs sh.exe. Duncan

On Sun, 2009-02-01 at 16:50 +0000, Sebastian Sylvan wrote:

...

...

Isn't this missing C library dependencies, which cabal head now warns about?

No, it's about packages using configure scripts which require MSYS on Windows.

In principle we should be able to notice this while doing the package dependency planning and report that we cannot install the package because it needs sh.exe.

I wonder *why* packages need sh though? Isn't cabal supposed to allow you to do that kind of scripting in Haskell rather than calling into platform-dependent shell scripts?

It does enable people to make portable packages, yes. It does not prevent people from using ./configure scripts, though as a community we do try to encourage people only to use them where it is essential.

Are there any specific reasons why people feel the need to use sh?

If you look at existing packages that use configure scripts you'll see some are pretty tricky, doing lots of checks in system header files for sizes of structures, values of constants and the presence of C functions in various header files. Some are trivial and should be done away with. For example the ones that just check if a C header / lib is present are unnecessary (and typically do not work correctly). The next point release of Cabal can do these checks automatically, eg: Configuring foo-1.0... cabal: Missing dependencies on foreign libraries: * Missing header file: foo.h * Missing C libraries: foo, bar, baz This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.

If the package is unix-only for other reasons (e.g. bindings to X or whatever) then it's obviously not a problem, but it appears to me that there's lots of packages that should be portable in principle that won't build on windows because it needs to run sh...

We need to do a survey of the existing packages that use configure scripts and identify what they are doing exactly. What we want to do is work out what checks they are performing and which ones could be turned into portable checks in cabal or in Setup.hs scripts. We want to know, if we added feature X to Cabal, then Y packages could give up their configure scripts. This would be an excellent task for some volunteer to take on. http://hackage.haskell.org/trac/hackage/ticket/482 Duncan

sebastian.sylvan:

-------------------------------------------------- From: "Don Stewart" Sent: Saturday, January 31, 2009 8:35 PM To: "Andrew Coppin" Cc: Subject: Re: [Haskell-cafe] 1,000 packages, so let's build a few!

...

andrewcoppin:

...

In celebration of Hackage reachin over 1,000 unique packages, I decided that I would re-visit the problem of attempting to build them on Windows.

Ah yes, I already have the tarball for stream-fusion-0.1.1, but I see that the latest release is 0.1.2.1. (Unfortunately, there doesn't appear to be any way to determine what the difference is between the two versions...)

the true way to install all of hackage is:

cabal install $(all my packages)

where cabal install solves it all.

If that had actually worked it would be great.... I must say that my own not-so-random sampling (basically "ooh that looks cool, let's try it") is probably at a 20% success rate or so... It's great when it does work, but it usually doesn't.

Usually it fails because some part of it tries to run unix shell scripts (and I try to avoid things which seem like they're unix only, even though they're no easy way of determining this, so these are packages that at least to me seemed like they could be perfectly portable if not for unix-specific installation procedures).

Windows people need to set up a windows@haskell.org to sort out their packaging issues, like we have for debian, arch, gentoo, freebsd and other distros. Unless people take action to get things working well on their platform, it will be slow going. -- Don

On Sun, 01 Feb 2009 15:01:28 +0000, Duncan Coutts wrote:

On Sat, 2009-01-31 at 16:50 -0800, Don Stewart wrote:

...

Windows people need to set up a windows@haskell.org to sort out their packaging issues, like we have for debian, arch, gentoo, freebsd and other distros.

Unless people take action to get things working well on their platform, it will be slow going.

Actually instead of going off into another mailing list I would encourage them to volunteer on the cabal-devel mailing list to help out. There is lots we could do to improve the experience on Windows and half the problem is we do not have enough people working on it or testing things.

That sounds like a great idea, but what specifically should Windows users do to help out? If we try to install a package on Windows and encounter a bug that we can't figure out, would it be sufficient to subscribe at http://www.haskell.org/mailman/listinfo/cabal-devel and to submit a bug report to cabal-devel@haskell.org ? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

Hi

So actually just having more Windows users subscribed to cabal-devel and commenting on tickets would be very useful, even if you do not have much time for hacking.

I believe that as soon as a Windows user starts doing that you'll start asking them for patches :-) There are a number of reasons that we have fewer Windows developers: * Some of it comes down to social reasons - for some reason it seems to be socially acceptable to belittle Windows (and Windows users) on the Haskell mailing lists and #haskell. * Some of it comes down to technical issues - for example not having cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake (although I've heard everyone argue against me, I've not yet heard a Windows person argue against me). * Part of it comes down to most developers not being Windows people. * A little is because Windows is a second class citizen even in the libraries, my OS is NOT mingw32 - mingw32 is not even an OS, its a badly typed expression! How would you like it if your OS was listed as Wine? Things like this tell me that Haskell isn't Windows friendly, at best its windows tolerant. * Things like Gtk2hs, which Windows users need building for them, don't release in sync with GHC, which makes it hard to use. * Windows machines don't usually have a C compiler, and have a very different environment - while the rest of the world is starting to standardise. I gave up on fighting the fight when people decided not to bundle cabal.exe with Windows - and now I'm too busy with my day job... Now I'd say Duncan is the most vocal and practical Windows developer, even overlooking the fact he doesn't run Windows. Thanks Neil

ndmitchell:

Hi

...

So actually just having more Windows users subscribed to cabal-devel and commenting on tickets would be very useful, even if you do not have much time for hacking.

I believe that as soon as a Windows user starts doing that you'll start asking them for patches :-)

There are a number of reasons that we have fewer Windows developers:

* Some of it comes down to social reasons - for some reason it seems to be socially acceptable to belittle Windows (and Windows users) on the Haskell mailing lists and #haskell.

* Some of it comes down to technical issues - for example not having cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake (although I've heard everyone argue against me, I've not yet heard a Windows person argue against me).

* Part of it comes down to most developers not being Windows people.

* A little is because Windows is a second class citizen even in the libraries, my OS is NOT mingw32 - mingw32 is not even an OS, its a badly typed expression! How would you like it if your OS was listed as Wine? Things like this tell me that Haskell isn't Windows friendly, at best its windows tolerant.

* Things like Gtk2hs, which Windows users need building for them, don't release in sync with GHC, which makes it hard to use.

* Windows machines don't usually have a C compiler, and have a very different environment - while the rest of the world is starting to standardise.

I gave up on fighting the fight when people decided not to bundle cabal.exe with Windows - and now I'm too busy with my day job... Now I'd say Duncan is the most vocal and practical Windows developer, even overlooking the fact he doesn't run Windows.

GHC doesn't bundle with cabal-install on any system. What is needed is not for the GHC team to be doing Windows platform packages, but for the Windows Haskell devs to build their own system, as happens on all the Unices. Take GHC's release, wrap it up with native installers, throw in useful libraries and executables like cabal. Done. It's not the GHC compiler team's job to build distro-specific bundles. So, windows@haskell.org anyone? Get the wiki going, get the set of tasks created. -- Don

ganesh.sittampalam:

Don Stewart wrote:

...

GHC doesn't bundle with cabal-install on any system.

What is needed is not for the GHC team to be doing Windows platform packages, but for the Windows Haskell devs to build their own system, as happens on all the Unices.

Take GHC's release, wrap it up with native installers, throw in useful libraries and executables like cabal. Done.

It's not the GHC compiler team's job to build distro-specific bundles.

So, windows@haskell.org anyone? Get the wiki going, get the set of tasks created.

Isn't the Haskell Platform going to do all this? Shouldn't interested people just help out there?

The platform is a set of blessed libraries and tools. The distros will still need to package that. To do that for Windows, we're still going to need a windows packaging team, along side Debian, Arch, Gentoo, Mac etc. -- Don

Don Stewart wrote:

The platform is a set of blessed libraries and tools. The distros will still need to package that.

To do that for Windows, we're still going to need a windows packaging team, along side Debian, Arch, Gentoo, Mac etc.

Right, so, let me make sure I understand this... 1. We sit down and pick a set of libraries that cover a useful range of subject areas, that are mature and stable, and that work well with each other. This is the "Haskell Platform". 2. For each OS, a team decides how best to deploy this set of libraries on that specific OS. Is that the plan?

Hi

GHC doesn't bundle with cabal-install on any system.

What is needed is not for the GHC team to be doing Windows platform packages, but for the Windows Haskell devs to build their own system, as happens on all the Unices.

Take GHC's release, wrap it up with native installers, throw in useful libraries and executables like cabal. Done.

GHC already takes the GHC release, bundles it up with a native installer, and then throws in useful executables like gcc. It just stops one hop short of "done". Windows is special, we already treat Windows special, but currently its just short of useable. Duncan: Saying cabal.exe isn't mature enough to go in 6.10 is a perfect reason, but one that you never gave at the time. If it isn't ready, then that's fine. But if thats the case, will it be in 6.12, or will the standard Windows instructions involve hunting around haskell.org for a prebuild Cabal.exe? Thanks Neil

On Mon, Feb 02, 2009 at 10:07:57AM +0000, Neil Mitchell wrote:

Hi

The nix package manager (although beeing primarly a linux tool) can run on cygwin as well (at least it did some time ago).. I'd suggest trying that to package windows libraries. It dose generate tag files for you automatically as well. At least it can build dependencies such as C libraries and so on for you automatically as well. Unfortunately I don't have time to work on the windows port. The cool thing about nix is: You can always switch back to the previous generation if something breaks. It organizes the packages like a memory management system. You only reference the target and the deps in between will be build / removed automatically for you if they are no longer used when running the nix garbage collector. There is another drawback: It definitely only works on a ntfs partition. On the other hand it does also support binary distributions and install software by clicking on links. In the end this is perfect for developping (IMHO) even if you have to learn a lot at the beginning. My major problem hindering my starting to work on this is that cygwin doesn't run on Vista running in kvm/ qemu. sh.exe exits and that's it. So if you have a solution for that I'd consider resuming work on it Sincerly Marc Weber

On Mon, 2009-02-02 at 10:07 +0000, Neil Mitchell wrote:

Hi

...

So actually just having more Windows users subscribed to cabal-devel and commenting on tickets would be very useful, even if you do not have much time for hacking.

I believe that as soon as a Windows user starts doing that you'll start asking them for patches :-)

Actually I deliberately didn't say that. I would be happy even with some people dispensing advise and testing things.

There are a number of reasons that we have fewer Windows developers:

* Some of it comes down to social reasons - for some reason it seems to be socially acceptable to belittle Windows (and Windows users) on the Haskell mailing lists and #haskell.

Yes plenty of it is social issues. Some of the perceptions in the other direction is that Windows users tend to expect everything to work and not be prepared to help. This may be what they're accustomed to but it tends to rub open source programmers up the wrong way.

* Some of it comes down to technical issues - for example not having cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake (although I've heard everyone argue against me, I've not yet heard a Windows person argue against me).

I think if it had been bundled with ghc-6.10 you'd have heard lots more Windows people complaining.

* Part of it comes down to most developers not being Windows people.

* A little is because Windows is a second class citizen even in the libraries, my OS is NOT mingw32 - mingw32 is not even an OS, its a badly typed expression! How would you like it if your OS was listed as Wine? Things like this tell me that Haskell isn't Windows friendly, at best its windows tolerant.

Note that cabal/hackage does not classify it that way.

* Things like Gtk2hs, which Windows users need building for them, don't release in sync with GHC, which makes it hard to use.

Hardly anything releases in sync with ghc and it's unrealistic to think that it can or should. The special problem for gtk2hs is that it has to be distributed as a binary so it's guaranteed not to work with new ghc releases where as most other packages will still build from source. Again this comes down to lack of developers and lack of access to Windows hardware. If we had the infrastructure we'd have auto-builders to make releases with new ghc releases. Perhaps that's something we can get people to work on. More automation is good. Building all of hackage on windows and reporting the results would be very useful to everyone. Not once but continuously.

* Windows machines don't usually have a C compiler, and have a very different environment - while the rest of the world is starting to standardise.

I gave up on fighting the fight when people decided not to bundle cabal.exe with Windows - and now I'm too busy with my day job... Now

The more I think about it the more I think that we fortuitously made the right decision not to bundle cabal-install with ghc-6.10. We didn't decide to do it due to immaturity but in hindsight that would have been an excellent reason. As I said before, I hope we'll be able to fix enough of the things that it'll be ok for the first platform release.

I'd say Duncan is the most vocal and practical Windows developer, even overlooking the fact he doesn't run Windows.

I'm going to obtain a license and set up a VM. Duncan