search

snowleopard / hadrian

Hadrian: a new build system for the Glasgow Haskell Compiler. Now merged into the GHC tree!
https://gitlab.haskell.org/ghc/ghc/tree/master/hadrian
MIT License
208 stars 39 forks source link

ctrl + c doesn't cancel build on windows #696

Open AndreasPK opened 5 years ago

AndreasPK commented 5 years ago

Ctrl + c does put me back into the shell, but the build continues.

I assume the actual build is done by a subprocess which happily continues after the primary process is killed and the signal isn't properly propagated.

snowleopard commented 5 years ago

Indeed. I believe this is a general Shake issue.

@ndmitchell Any ideas what could be done with this?

ndmitchell commented 5 years ago

@AndreasPK what is your shell? Cygwin? Mingw? Straight command prompt? The more layers of wrapping you add the less likely it is to work - but I don't think this is necessarily the fault of Shake.

AndreasPK commented 5 years ago

The default mingw shell (mintty). Which as I understand is also the only supported work flow.

I was using build.sh instead build.bat though as the later was broken when I tried.

snowleopard commented 5 years ago

Let me record my "workaround" here: when using MSYS2 MINGW64 Shell, I terminate Hadrian using the Task manager, which is awkward, but seems to work.

snowleopard commented 5 years ago

@Mistuke says the following on ghc-devs:

Indeed. I hope it's not difficult to fix this, but I'm not sure where to start. Any suggestions are very welcome.

It is unfortunately, because it's not a bug. Odds are both of you are using MinTTY which people blindly recommend to use. The problem is MinTTY is not designed to run native Windows applications, it is designed to run ported POSIX applications. e.g. things linked against the msys2/cygwin runtime. Because of this it implements a very intrusive hack in order to be able to handle signals the way they would be under a posix application, which simply isn't compatible with Windows signals see https://github.com/mintty/mintty/issues/56

Because your build is triggered by a batch file, when you press ctrl+c mintty will terminate the parent process indiscriminately if it's a script, e.g. the batch process is killed but none of the children are. This is why ghci has ghcii.sh as a workaround. e.g. why pressing ctrl+c terminate ghci instead of the computation as we can't.

this is why you should not use MinTTY with a native Windows application. MinTTY also introduces a number of character encoding problems for native Windows applications, see https://github.com/mintty/mintty/wiki/Tips#inputoutput-interaction-with-alien-programs. In short, the issues you're seeing are by design.

Now you have two options:

1) Don't use mintty, instead use something like ConEmu https://conemu.github.io/ with bash.exe from msys2 as the terminal host.This will work for Native application but have issues with interactive posix applications like msys2 gdb (mingw64 gdb should in theory work fine though, but it's slightly more limited) and i.e.. tmux won't work. (the problems are thus flipped).

2) Use WinPTY https://github.com/rprichard/winpty to wrap native application calls (you can just install it via pacman), which works and you can keep using MinTTY, but this does have a slight performance overhead as the reason it works is that it spawns a hidden buffer and scrapes output from it and send events to it to check the native behavior for Windows applications.

TL;DR; It's not a simple issue, the application can only deal with one signal processing method at a time.