Fails on Windows w/o MSYS about network HOT 14 CLOSED

Cabal won't support multiple build types for projects and you can't have different build-types for internal libraries. Also all Windows toolchain distributions ship msys2 these days.

from network.

1. Wouldn't it be smart to eradicate the use of GNU toolchain to keep the library cross-platform?

If it could be made to work, but someone needs to do the work.

2. If configure is a strictly must-use tool, shouldn't we ask to include MSYS into Haskell Platform with proper default setup?

The platform does included MSYS (but I'm not sure about the PATH setup) and the network package is already compiled in the distribution so the users don't need to use configure to use the network shipped with the platform.

from network.

@kazu-yamamoto

The default setup is still wrong. network package is still rendering software unusable on Windows.

idris-0.12.2 depends on network-2.6.3.1 which failed to install.

I see that now the package is supported by less opinionated person. Could we at least reopen this and mark as a bug?

from network.

Unlike cabal, stack doesn't have any problems with this package.

There is no inherent need in unix toolchain. Terrorizing Haskell users on Windows for 4 years is kinda mean.

from network.

@polkovnikov-ph I'm very sorry for your inconvenience. I'm not a right person to tackle this issue because I don't have Windows environment.

@eborden Do you handle this issue?

@snoyberg Could you explain why stack does not have this kind of problems.

from network.

Stack was designed to work around this kind of issue by providing a Unix compatible toolchain. My understanding is that the Haskell Platform implemented a similar solution, so I'm not sure why this would be a problem.

from network.

@kazu-yamamoto I'm very sorry to remind about this issue again, especially as it affects only hobby usage of Haskell on Windows.

@snoyberg The problem is that Unix compatible toolchains are no fun on Windows, and they tend to fail due to spaces, unicode in paths or just randomly. That's inherent problem of software that was primarily developed on Unix compatible systems. Haskell, on the other hand, makes no assumptions about the system, including POSIX compatibility. That's why having one of the main packages to depend on Unix toolchain is odd, to say the least.

from network.

@polkovnikov-ph I do empathize. I've opened #251 in response. I'd love to better serve Windows users.

from network.

@eborden I think there's no need in separate Windows maintainer. Once built it works fine, which implies that cbits are already working on Windows properly. The only thing to fix is Setup.hs that calls autoconf tools instead of doing same things in Haskell. It requires (almost) no Windows knowledge to port autoconf code to Haskell.

from network.

@polkovnikov-ph Can you produce a failing test case on appveyor?
https://github.com/haskell/network/blob/master/appveyor.yml

from network.

@polkovnikov-ph If we have problems unique to Windows (not building stuff), @eborden and I cannot fix them. So, it would be nice if we had a new maintainer.

from network.

Hmm I believe this should be working with platform now as well. Though their fix of using dos shortnames in paths isn't a complete fix.

from network.

I've been talking with the cabal people to support a way to keep configure scripts for non-Windows OSes and for Windows provide an opt-out with a pre-generated config.status file. On Windows the checks will always result in the same results, so it's not a very useful restriction.

I probably won't get to implementing it this month, but early next month I should have time for it (fighting too many fires at once). We can then have network use this new build-type.

This would remove the need to have stack, platform or msys2 to build network and a lot of other packages.

from network.

@Mistuke Could you try this again?

from network.