There was never any investigation done to determine whether using
jemalloc was actually a net benefit for nvim. It has been a portability
limitation and adds another factor to consider when triaging issues.
Use uv_set_vterm_state() to override libuv's guess.
See https://github.com/libuv/libuv/pull/1873/ for discussion.
This commit uses a terminal-detection approach based on
GetProcessImageFileNameW(...), which will be reverted in the following
commit. The approach was intended to handle the case of running in
winpty (:terminal), but we will add $NVIM env var for that.
Also add some support for ConEmu, cygwin.
Remove libuv-overlapped.patch since UV_OVERLAPPED_PIPE was included in
libuv v1.21.0:
62a0f763a7
Notable changes since v1.12:
- 1.16.0
- uv_os_getppid(): get parent PID
- "win,tty: improve SIGWINCH support" (v1.15.0)
- 1.18.0
- uv_os_getpid()
- 1.19.0
- Windows: uv_kill() pid 0 now means "current process group", like unix.
890eedaf59
- 1.20.0
- unix,spawn: respect user stdio flags for new pipe
c409b3fcff
In the 20180331 release, the format was slightly changed:
> 20180331
> + improve terminfo write/read by modifying the fourth item of the
> extended header to denote the number of valid strings in the extended
> string table (prompted by a comment in unibilium's sources).
Since the number of valid string capabilities is not necessarily the
same as extstrslen, it's not possible to sanity check the total number
of items up front anymore.
- Since the jemalloc upgrade to 5.1.0, I'm seeing weird behavior such as
infinite loops inside jemalloc routines.
- VimR maintainer reported major performance regression correlated with
jemalloc 5.1.0.
ref https://github.com/neovim/neovim/pull/7808
reverts 765515010f
- We need the gettext tools (msgmerge.exe) because these aren't built
when we build from source (not trivial).
- We can use the pre-built libiconv-2.dll for DYNAMIC_ICONV_DLL.
It's only appropriate to set CMAKE_MAKE_PROGRAM to gmake when we're
using the "Unix Makefiles" generator. On QB, the nodes have Ninja
available and will use it, which means CMAKE_GENERATOR is set to
"Ninja". Setting CMAKE_MAKE_PROGRAM was forcing the build to use gmake
instead of ninja, which was causing the build failure.
