Cannot install new version of network on Windows out of the box

[ndmitchell]

If I install from MinGHC (https://github.com/fpco/minghc) then I can install newer versions of network with cabal install. If I instead from the platform I can't.

[randen]

Since the HP only includes (via the GHC releases) enough of mingw for compiling and linking, a typical Windows user would not have the additional build-related tools required by a linux-configure-style of build (which is what the network package is). And so that is why typical users would not be able to build the network package.

Off the top of my head, some possibilities, but surely there are more I haven't thought of and these are not necessarily a thorough examination of the pros/cons, so we can use this for discussion.

• network package could be modified to build without requiring all the linux-configure-style tools (or, at least done that way in the Windows-build case; this may be a nightmare for the network package maintainer?)
• Similar to HP, cabal, etc., a network installer could be distributed which would include the pre-built network package (sorry, just a brain-stormed idea, so may be nonsense--perhaps only the pre-compiled .o files?). I'm unsure how much of the configure script would actually result in differences given a particular Windows platform (e.g., 64-bit Win7).
• HP could include more from the mingw project such that at least the network package could be built (I haven't looked at paring it down, but MSys64 unspooled onto my disk is about 170MB, and the msys2 zip file is about 30MB so HP installers and their installed footprints would increase some)
• HP could be modified to start from the corresponding minghc build rather than the ghc release tarball (the Windows HP and the other platforms' HP would be built somewhat differently; similar notes about size of HP installed and installed footprint as above)

Note that for any solution which puts the MSys tools onto the user's PATH, that will cause people trouble, as there are executables which shadow some Windows tools (e.g., find). Perhaps only a batch file which amends the PATH appropriately, then launches sh.exe?

Side question: it looks like the network package, when building on Windows in MSys, does not use autoconf just the already built configure script? I can't recall for sure, but when I was building the HP 2014, the autoconf tools were not used.

[23Skidoo]

Note that for any solution which puts the MSys tools onto the user's PATH, that will cause people trouble.

We should provide a shortcut for starting an MSYS session with our versions of gcc, ghc and MSYS tools in PATH. This is also useful when the user has multiple versions of HP installed.

[ndmitchell]

MinGHC installs the script minghc-7.8.3.bat on the $PATH which modifies the $PATH to bring the rest of the tools into scope, that's very useful. We looked at a number of potential solutions for network, and shoving a small subset of MinGW onto the path was the best one we came up with. Note that we don't ship things like find, but do ship 92 other binaries.

[23Skidoo]

@ndmitchell

Does this break if some other installer that comes with its own copy of MSYS tools (e.g. Git's) modifies PATH afterwards?

[hvr]

@randen btw, while this ticket is specifically about the network package, it's not the only package with build-type: configure on Hackage affected. So any workaround that requires to modify network doesn't do much for the other packages affected.

[randen]

True, modifying the network package as a work-around won't help any other configure-type packages, but for any configure-type packages which use something outside the scope of the 92 binaries shipped with the sub-set of MSys, they won't build with minghc either.

It seems clear from this that the title of this issue is not very useful, then. Is it about network package or not? If not, then let's close this and submit something (or re-title this one) that says what the issue is. Maybe: HP on Windows cannot install packages with a cabal build-type of "configure" without adding additional tools. That's currently noted (or at least, understood) as a restriction, but actually doesn't seem to have an open issue for it.

I take all of this as good news, however, indicating that there are people who want the kind of convenience provided by HP on Windows, they just want it to be better or something else.

[Rufflewind]

Does this break if some other installer that comes with its own copy of MSYS tools (e.g. Git's) modifies PATH afterwards?

Git gives the user a choice as to whether it adds its tools to PATH. By default it does not.

[ndmitchell]

Note that while supporting everything with configure would be great, it's diminishing returns. Network accounts for about 90% of the troubles. If you just fixed network, you've made a great start, and I think network should be the focus. If you can get all configure packages, or some large subset, that's a nice bonus.

The subset of tools MinGHC ships with seem to be a good spot. It seems most Haskell packages which use configure scripts but don't depend on 3rd party libraries tend to work. I haven't observed any clashes, but I don't generally care (or even know) which less is on my $PATH as long as it works like less. However, I don't believe the MinGHC subset is chosen with any great care or attention, there are probably better subsets out there.

[gbaz]

closing in favor of #207