Repository navigation
Fails on Windows w/o MSYS #89
Description
Activity
- 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.
- 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.
The default setup is still wrong.
networkpackage 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?
Unlike
cabal,stackdoesn'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.
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.
@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.
@eborden I think there's no need in separate Windows maintainer. Once built it works fine, which implies that
cbitsare already working on Windows properly. The only thing to fix isSetup.hsthat callsautoconftools instead of doing same things in Haskell. It requires (almost) no Windows knowledge to portautoconfcode to Haskell.@polkovnikov-ph Can you produce a failing test case on appveyor?
https://github.com/haskell/network/blob/master/appveyor.yml@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.
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.
I've been talking with the
cabalpeople to support a way to keepconfigurescripts for non-Windows OSes and for Windows provide an opt-out with a pre-generatedconfig.statusfile. 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,platformormsys2to build network and a lot of other packages.@Mistuke Could you try this again?
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.
Reacted by reverofevil
cabal: The package has a './configure' script. This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin.
There are some solutions over the Internet (like this one http://www.haskell.org/pipermail/haskell-cafe/2012-February/099633.html) but none worked for me. MSYS can't connect to mingw installed in the path with spaces in it, which is the default one for Haskell Platform, and which is the only one used by Agda installer.
configureis a strictly must-use tool, shouldn't we ask to include MSYS into Haskell Platform with proper default setup?