semantic
semantic copied to clipboard
github
Windows support
Nothing about the library ~or executable~ is Unix-specific, so we should support Windows. Creating this issue to track it.
We should also make sure that this builds and runs with WSL, though I can’t imagine a reason why it wouldn’t.
We should use this to attempt to provide signal handling on Windows. https://hackage.haskell.org/package/signal-0.1.0.4/docs/System-Signal.html
We should also make sure that this builds and runs with WSL, though I can’t imagine a reason why it wouldn’t.
I poked at this today hoping it was pretty straightforward but found a strange build error:
Failed to build ghc-tcplugins-extra-0.3.
Build log (
/home/shiftkey/.cabal/logs/ghc-8.6.4/ghc-tcplugins-extra-0.3-20b576c0cf25abb37fd1483fca4b604095b0b3e8e9197f3d2a057b4ad43fde2c.log
):
Configuring library for ghc-tcplugins-extra-0.3..
Preprocessing library for ghc-tcplugins-extra-0.3..
Building library for ghc-tcplugins-extra-0.3..
[1 of 1] Compiling GHC.TcPluginM.Extra ( src/GHC/TcPluginM/Extra.hs, dist/build/GHC/TcPluginM/Extra.o )
/usr/bin/ld.gold: error: cannot find -ltinfo
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
cabal: Failed to build ghc-tcplugins-extra-0.3 (which is required by
exe:semantic from semantic-0.6.0). See the build log above for details.
Not sure what it might point to, but happy to try things if you think I'm just missing some dependency.
Full log: https://gist.github.com/shiftkey/91fa9f639d80419938fef7f2417754fc
@shiftkey Looks like WSL doesn’t provide libtinfo out of the box, which is I guess what ghc-tcplugins-extra uses for… line editing support, I guess? That might be it…
tinfo also had a recent soversion bump from 5 to 6, which caused us problems on our internal Docker builds that were based on too old of a Debian image. (The tinfo dep was showing up in the resulting built binaries, IIRR!) But since this is a link-time error, you're right @patrickt that here it looks more like it's just missing, and not a version-mismatch error.
...at the risk of stating the obvious, have you tried already with apt-get install libtinfo-dev ?
@hvr that's a good point!
WSL is a very minimal install, so I had to install these additional packages to address build failures:
$ apt-get install libtinfo-dev libz-dev libutf8proc-dev
The other thing I had to do was change core.autocrlf from true (which is set by default in the WSL home directory, probably for interop reasons with Windows) to false and reset the working directory state. The line endings change seems to trigger alot of test failures, but I'll dig into that another time and see whether it needs some documentation tweaks.
The cabal new-test now succeeds but doesn't exit cleanly after emitting the test suite log with a CTRL + C - probably just some interop issue.
With those tweaks I was able to get a working built/test/run of semantic going and see semantic --help work for f7bc9b85ee04bf37f7bff15e75d4a5fdf8e956ed, so :tada:
I tried to build on windows and after finding this issue I'm not surprised that it did not work :).
I'm posting my result here for reference.
$ PATH=$(stack path --bin-path --resolver lts-14.2):$PATH cabal new-build
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
[__0] trying: semantic-0.7.0.0 (user goal)
[__1] next goal: unix (dependency of semantic)
[__1] rejecting: unix-2.7.2.2 (library is not buildable in the current
environment, but it is required by semantic)
[__1] rejecting: unix-2.7.2.1, unix-2.7.2.0, unix-2.7.1.0, unix-2.7.0.1,
unix-2.7.0.0, unix-2.6.0.1, unix-2.6.0.0, unix-2.5.1.1, unix-2.5.1.0,
unix-2.5.0.0, unix-2.4.2.0, unix-2.4.1.0, unix-2.4.0.2, unix-2.4.0.1,
unix-2.4.0.0, unix-2.3.2.0, unix-2.3.1.0, unix-2.3.0.0, unix-2.2.0.0, unix-2.0
(conflict: semantic => unix^>=2.7.2.2)
[__1] fail (backjumping, conflict set: semantic, unix)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: semantic, unix
Using git bash as the shell.
Yup, looks like we need to divest the library core from the unix package. This will be feasible once we tackle #136, as the only usages of the unix package are in the CLI tooling.
I tried to build on windows and I got the same results as @Neppord.
c:\Users\dani_\gitrepos\semantic\semantic>script/bootstrap
Script started, file is /bootstrap
sh-4.4$ cabal v2-build all
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
[__0] trying: semantic-0.11.0.1 (user goal)
[__1] next goal: unix (dependency of semantic)
[__1] rejecting: unix-2.7.2.2 (library is not buildable in the current
environment, but it is required by semantic)
[__1] rejecting: unix-2.7.2.1 (conflict: semantic => unix^>=2.7.2.2)
[__1] skipping: unix-2.7.2.0, unix-2.7.1.0, unix-2.7.0.1, unix-2.7.0.0,
unix-2.6.0.1, unix-2.6.0.0, unix-2.5.1.1, unix-2.5.1.0, unix-2.5.0.0,
unix-2.4.2.0, unix-2.4.1.0, unix-2.4.0.2, unix-2.4.0.1, unix-2.4.0.0,
unix-2.3.2.0, unix-2.3.1.0, unix-2.3.0.0, unix-2.2.0.0, unix-2.0 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '^>=2.7.2.2' from 'semantic')
[__1] fail (backjumping, conflict set: semantic, unix)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: semantic, unix
As @patrickt pointed, it seems easy to refactor the CLI tooling and make the library win-compatible. Is there any estimate for that? Thank you!!
