- fs: fix uv_fs_copyfile if same src and dst
- build, core, unix: add support for Haiku
- unix: make uv_cwd() report UV_ENOBUFS
- unix: make uv_fs_read() fill all buffers
I found it often irritation to see the same comment about "DEPENDS"
there all the time. This uses the LuaRocks rock name as a comment
instead (which is hard to parse from the recipe), moves the note about
DEPENDS to the top (extended), and fixes/aligns some whitespace.
With LuaRocks 3 it will include the version, and this will make the
upgrade easier then.
It also makes sense to factor this out in general for clarity already.
Pulled out of https://github.com/neovim/neovim/pull/10292.
This is required to (re)build e.g. libluv when the version changes
(which triggers a new download).
With `make deps`, changing the `LUV_URL`/`LUV_SHA256`, and `make deps` again:
Before:
> Up-to-date: /home/daniel/Vcs/neovim/.deps/usr/lib/libluv.a
After:
> Installing: /home/daniel/Vcs/neovim/.deps/usr/lib/libluv.a
See with https://github.com/neovim/neovim/pull/10358 - where .deps
contained libluv 1.29, the merge updates it to 1.30, but then it failed
to link because `libluv.a` is considered to be up-to-date (after
downloading the new version).
Note that header files get installed, since they have the original time
stamp, but `libluv.a` is being generated (does not use the timestamp
from the archive here, but needs to get rebuild).
It could be argued that the build system of the included project should
catch/handle this, but it seems to be good practice to clean the binary
/ build dir with a new download to start from scratch.
Ref: https://gitlab.kitware.com/cmake/cmake/issues/19452
Also fixes cmake/BuildLuv / luv-static: use name with -DTARGET for
download command, and pass (shared) `SRC_DIR` explicitly instead.
* build: update some test dependencies
* luacheck ignores
* BuildLua: add ${BUSTED} to depends for ${BUSTED_LUA}
This is required to rebuild it when busted gets updated.
Keeps using add_definitions for compatibility with older CMake.
Newer CMake (3.12) would have `add_compile_definitions`, but it is not
required, since `add_defitions` was meant to be used for
compile/preprocessor definitions initially anyway.
Ref: https://github.com/neovim/neovim/pull/4389
This regressed in 204ec6337.
Currently it would detect/use lua5.3 from the system, but in general
luajit is / should be preferred.
Noticed this due to nvim-client failing to build with Lua 5.3
(https://github.com/neovim/lua-client/pull/43).
This was added in 4c92a0bac to help with debugging, but could also have been
just moved there instead of disabling it manually (which was done due to
issues on Travis with OSX).
Since the JIT is the main feature of luajit, we should not disable it,
especially not during compile time.
$ bzr log --line --forward -r v0.20..
372: Paul "LeoNerd" Evans 2017-03-30 {v0.20} Bumped VERSION to 0.20
373: Paul "LeoNerd" Evans 2017-04-10 [merge] Apply typo fixes from jamessan
374: Paul "LeoNerd" Evans 2017-11-29 Build termkey.pc by invoking a small shell script instead of sed'ing a template
375: Paul "LeoNerd" Evans 2018-03-29 Implement mouse key parsing (thanks Marc André Tanner <mat@brain-dump.org>)
376: Paul "LeoNerd" Evans 2019-01-02 Bugfix for infinite CPU spin on TERM=dumb, which has no terminfo key strings
377: Paul "LeoNerd" Evans 2019-02-14 Fix a couple of valgrind-cleanness errors in DEBUG mode
378: Paul "LeoNerd" Evans 2019-02-14 Fix valgrind uninitialised value warning
379: Paul "LeoNerd" Evans 2019-02-14 Remember to unibi_destroy() even if we never (lazily) loaded terminfo
380: Paul "LeoNerd" Evans 2019-02-14 Bugfix memory leak in TI driver on xterm
381: Paul "LeoNerd" Evans 2019-02-17 driver-ti.c does not need a separate TYPE_MOUSE node type since TERMKEY_TYPE_MOUSE already exists
382: Paul "LeoNerd" Evans 2019-02-17 Perform TI string lookup by iterating all the strings we care about, rather than iterating everything in the DB; that way a hook function can invent new strings
383: Paul "LeoNerd" Evans 2019-02-17 Avoid nonstandard \e sequence in unit tests (via neovim https://github.com/neovim/neovim/blob/master/third-party/patches/libtermkey-Fix-escape-sequences-for-MSVC.p...
384: Paul "LeoNerd" Evans 2019-02-17 win32: Win32 lacks <unistd.h> and S_ISFIFO()
385: Paul "LeoNerd" Evans 2019-02-17 win32: Win32 needs help to get ssize_t
386: Paul "LeoNerd" Evans 2019-02-17 win32: Win32 has no <termios.h>
387: Paul "LeoNerd" Evans 2019-02-17 win32: Win32 has no poll() so cannot provide termkey_waitkey()
388: Paul "LeoNerd" Evans 2019-02-17 win32: Win32 has no <strings.h> and needs help getting strcasecmp()
389: Paul "LeoNerd" Evans 2019-02-17 Write the version into the .pc file at 'make install' time so we don't get@VERSION@ from source
390: Paul "LeoNerd" Evans 2019-02-19 {v0.21} Bumped VERSION to 0.21
391: Paul "LeoNerd" Evans 2019-02-19 Bugfix to missing TERMIOS support
392: Paul "LeoNerd" Evans 2019-02-19 Fix offbyone buffer overflow in sprintf calculation of key names (neovim #9630)
393: Paul "LeoNerd" Evans 2019-02-19 {v0.21.1} Remove a pointless (and warny) cast
Our local patches are now part of the libtermkey repo and get removed.
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.
