As long as the return value of `CtrlRoutine` indicates that it has been
handled, do not insist on the process to go away. This is in line with
`SIGINT` handlers on Linux/Unix/macOS that can prevent the process from
terminating on the process' side.
This brings over https://github.com/msys2/msys2-runtime/pull/50 into
MSYS2-packages.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea is that we handle Ctrl+C not by terminating the processes
(which would reflect `kill -KILL`, not `kill -INT`) but by imitating
what Windows does in a CMD window: we inject a remote thread that runs
the `CtrlRoutine` function. This lets the `atexit()` handlers and the
ConsoleCtrlEvent handlers do their job.
This commit brings the goodness from
https://github.com/msys2/msys2-runtime/pull/31 over into MSYS2-packages,
which cherry-picked and edited the patches from Git for Windows.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch synchronizes msys2/MSYS2-packages/msys2-runtime with
msys2/msys2-runtime after merging
https://github.com/msys2/msys2-runtime/pull/16.
We specifically override Cygwin's symlink() behavior to make deep copies
instead of creating a special-crafted system file that Cygwin (MSYS2,
and only those two) will recognize as symbolic link.
The patch to override this behavior is incomplete, though: it hacks up
the WSYM_sysfile code path, which causes all kinds of problems:
- Contrary to the documentation, MSYS=winsymlinks:native won't fall back
to creating Cygwin-style symbolic links. Instead, it (quite
surprisingly) creates deep copies instead.
- There is no way to opt into the original Cygwin behavior because that
code path is now dead code.
- The fact that the WSYM_sysfile code path is modified to do something
very different from what it is intended to do means that all changes
that Cygwin makes to that code path have to be inspected, and
occasionally even more hacks have to be put on top, such as 44bb133,
where we specifically had to disable Cygwin's code to try creating WSL
symlinks before falling back to creating system files instead).
Let's fix this by introducing a proper new mode:
MSYS=winsymlinks:deepcopy. This mode is made the default so
that users should be unaffected by this PR.
Users wishing to let the MSYS2 runtime create Cygwin-style
symbolic links can ask for that by setting
MSYS=winsymlinks:sysfile.
By fixing this issue, we can now stop disabling Cygwin's WSL
symlink behavior, too: it is in the sysfile code path and
won't affect the default behavior of the MSYS2 runtime.
While at it, the indentation of the original patch is fixed,
too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To make it easier to experiment with it, we now also support
`MSYS=enable_pcon` (in addition to the equivalent but unintuitive
`MSYS=nodisable_pcon`).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* msys2-runtime: add a shell script to generate the patches from msys2/Cygwin
The idea is to commit a change incrementing the `pkgver`, then running
this script, and then amending the commit.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* msys2-runtime: work around Cygwin's source code containing symlinks
It is a bit unfortunate that MSYS2 substitutes symlinks by deep copies,
by default. Git, for example, claims that it cannot do symlinks, but
Cygwin now needs this. Let's make do with that default.
The strategy we use is simple: we override the auto-detected
`core.symlinks` setting. That will result in a dirty worktree, of
course: deep copies are not symlinks, and `git status` will detect it.
But that does not matter, as the build will now work ("deep" copies of
those header files will work just as well as real symlinks would have
done).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* msys2-runtime: upgrade to v3.1.4
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
