ref #9280
Introduce the `vim.compat` module, to help environments with system Lua
5.2+ run the build/tests. Include the module implicitly in all tests.
ref #8677
legacy `vim` module:
beep
buffer
command
dict
eval
firstline
lastline
line
list
open
type
window
If check_c_source_compiles() succeeded (HAVE_WORKING_LIBINTL is set)
then the result of find_xxx() doesn't matter. This happens on systems
(linux+glibc) where libintl is available passively.
This allows `find_package(LibIntl REQUIRED)` to work and will still
correctly fail (REQUIRED) on systems lacking libintl.
This helps to figure out what the problem is, e.g. in my case I have
lua51-mpack installed to be used with luajit, but it is broken (missing
libmpack).
With this patch you get:
-- Checking Lua interpreter /usr/bin/luajit
/usr/bin/luajit: error loading module 'mpack' from file '/usr/lib/lua/5.1/mpack.so':
libmpack.so.0: cannot open shared object file: No such file or directory
stack traceback:
[C]: at 0x55fcf0166fb0
[C]: in function 'require'
(command line):1: in main chunk
[C]: at 0x55fcf01188a0
-- [/usr/bin/luajit] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.1
/usr/bin/lua5.1: error loading module 'mpack' from file '/usr/lib/lua/5.1/mpack.so':
libmpack.so.0: cannot open shared object file: No such file or directory
stack traceback:
[C]: ?
[C]: in function 'require'
(command line):1: in main chunk
[C]: ?
-- [/usr/bin/lua5.1] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.2
/usr/bin/lua5.2: (command line):1: module 'mpack' not found:
no field package.preload['mpack']
no file '/usr/share/lua/5.2/mpack.lua'
no file '/usr/share/lua/5.2/mpack/init.lua'
no file '/usr/lib/lua/5.2/mpack.lua'
no file '/usr/lib/lua/5.2/mpack/init.lua'
no file './mpack.lua'
no file '/usr/lib/lua/5.2/mpack.so'
no file '/usr/lib/lua/5.2/loadall.so'
no file './mpack.so'
stack traceback:
[C]: in function 'require'
(command line):1: in main chunk
[C]: in ?
-- [/usr/bin/lua5.2] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua
/usr/bin/lua: (command line):1: module 'mpack' not found:
no field package.preload['mpack']
no file '/usr/share/lua/5.3/mpack.lua'
no file '/usr/share/lua/5.3/mpack/init.lua'
no file '/usr/lib/lua/5.3/mpack.lua'
no file '/usr/lib/lua/5.3/mpack/init.lua'
no file './mpack.lua'
no file './mpack/init.lua'
no file '/usr/lib/lua/5.3/mpack.so'
no file '/usr/lib/lua/5.3/loadall.so'
no file './mpack.so'
stack traceback:
[C]: in function 'require'
(command line):1: in main chunk
[C]: in ?
-- [/usr/bin/lua] The 'mpack' lua package is required for building Neovim
CMake Error at CMakeLists.txt:459 (message):
A suitable Lua interpreter was not found.
While this makes it more verbose for the expected error case ("module
'mpack' not found"), the behavior before this patch hides too much.
This is the old output:
-- Checking Lua interpreter /usr/bin/luajit
-- [/usr/bin/luajit] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.1
-- [/usr/bin/lua5.1] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.2
-- [/usr/bin/lua5.2] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua
-- [/usr/bin/lua] The 'mpack' lua package is required for building Neovim
CMake Error at CMakeLists.txt:459 (message):
A suitable Lua interpreter was not found.
This is for when the whole configuration runs (i.e. after `make
distclean`), afterwards only one Lua interpreter gets checked only.
closes#7239
The old behaviour was to set CMAKE_INSTALL_MANDIR to /usr/local/man
when MANPREFIX wasn't defined. This caused mismatching installation
paths when the installation prefix wasn't /usr/local.
This fix explicitely checks that the prefix is /usr/local to change
the value of CMAKE_INSTALL_MANDIR, and uses the default behaviour
otherwise, as /usr/local is the exception rather than the norm
(as per man hier(7)).
Handling of process exit is still broken. It detects the moment when the
child process exits, then quickly stops polling for process output. It
should continue polling for output until the agent has scraped all of the
process' output. This problem is easy to notice by running a command like
"dir && exit", but even typing "exit<ENTER>" can manifest the problem --
the "t" might not appear.
winpty's Cygwin adapter handles shutdown by waiting for the agent to close
the CONOUT pipe, which it does after it has scraped the child's last
output. AFAIK, neovim doesn't do anything interesting when winpty closes
the CONOUT pipe.
Tests that check localized error messages need a stable locale, else
errors like this occur:
[ FAILED ] 2 tests, listed below:
[ FAILED ] ...npack/file/vim/neovim/test/functional/eval/null_spec.lua @ 29: NULL list is accepted as an empty list by writefile()
...npack/file/vim/neovim/test/functional/eval/null_spec.lua:30: Expected objects to be the same.
Passed in:
(string) '
E484: Cannot open file Xtest-functional-viml-null'
Expected:
(string) '
E484: Can't open file Xtest-functional-viml-null'
stack traceback:
...npack/file/vim/neovim/test/functional/eval/null_spec.lua:30: in function <...npack/file/vim/neovim/test/functional/eval/null_spec.lua:29>
[ FAILED ] ...k/file/vim/neovim/test/functional/ex_cmds/write_spec.lua @ 81: :write errors out correctly
...k/file/vim/neovim/test/functional/ex_cmds/write_spec.lua:97: Expected objects to be the same.
Passed in:
(string) 'Vim(write):E510: Cannot make backup file (add ! to override)'
Expected:
(string) 'Vim(write):E510: Can't make backup file (add ! to override)'
stack traceback:
...k/file/vim/neovim/test/functional/ex_cmds/write_spec.lua:97: in function <...k/file/vim/neovim/test/functional/ex_cmds/write_spec.lua:81>
10 SKIPPED TESTS
2 FAILED TESTS
-- Output to stderr:
2017/07/29 00:41:32 ERROR 31133/open_log_file:170: Logging to stderr, failed to open $NVIM_LOG_FILE: Xtest-startup-xdg-logpath/nvim/log
2017/07/29 00:41:32 WARN 31133/call_set_error:815: RPC: ch 1 was closed by the client
CMake Error at /home/shlomif/Download/unpack/file/vim/neovim/cmake/RunTests.cmake:50 (message):
Running functional tests failed with error: 1.
FAILED: CMakeFiles/functionaltest
cd /home/shlomif/Download/unpack/file/vim/neovim/build && /usr/bin/cmake -DBUSTED_PRG=/home/shlomif/Download/unpack/file/vim/neovim/.deps/usr/bin/busted -DLUA_PRG=/home/shlomif/Download/unpack/file/vim/neovim/.deps/usr/bin/luajit -DNVIM_PRG=/home/shlomif/Download/unpack/file/vim/neovim/build/bin/nvim -DWORKING_DIR=/home/shlomif/Download/unpack/file/vim/neovim -DBUSTED_OUTPUT_TYPE=nvim -DTEST_DIR=/home/shlomif/Download/unpack/file/vim/neovim/test -DBUILD_DIR=/home/shlomif/Download/unpack/file/vim/neovim/build -DTEST_TYPE=functional -DSYSTEM_NAME=Linux -P /home/shlomif/Download/unpack/file/vim/neovim/cmake/RunTests.cmake
ninja: build stopped: subcommand failed.
Makefile:102: recipe for target 'functionaltest' failed
make: *** [functionaltest] Error 1
- Do not delete it: may need to inspect it after tests finished.
- Avoids writing to stderr in cases where the test-local $XDG_DATA_HOME
was not created yet.
This also removes LINT_FILE environment variable, other then that functionality
is kept. It is expected that developers needing partial linting will use `make
lint`, touching interesting file before (if not done already by writing to
them).
Allows linting only modified files and linting multiple files in
parallel. In the current state is rather slow because errors.json is
a 6 MiB file and needs to be reparsed each time.
Results on my system (6-core):
# In build dir, actually parallel
make -j5 clint 241.24s user 8.39s system 334% cpu 1:14.74 total
# In root, one process
make -j5 clint 60.69s user 0.37s system 93% cpu 1:05.19 total
In both cases download time included.
That is not well for travis (though I would keep travis as-is because
new variant will fail before checking all files), but already good
enough for regular development: total times are nearly identical and
this is the *full* build, further `make -C build clint` will check only
modified files.
- Add support for TEST_FILE to the `oldtest` target, for consistency
with the busted/lua tests.
Caveat: with the busted/lua tests TEST_FILE takes a full path, whereas
for `oldtest` it must be "test_foo.res".
- Add support for NVIM_PRG, again so that all test-related targets are
consistent.
- Use consistent name for NVIM_PRG. But still need to support NVIM_PROG
for QuickBuild CI.
Note: The `oldtest` target is driven by the top-level Makefile, because
it requires a TTY. CMake 3.2 added a USES_TERMINAL flag to
add_custom_target(). But we support CMake 2.8...
add_custom_target(oldtest
COMMAND make clean
COMMAND make NVIM_PRG=$<TARGET_FILE:nvim> $ENV{MAKEOVERRIDES}
DEPENDS nvim
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/src/nvim/testdir"
USES_TERMINAL true
)
This was a workaround from long ago, but it doesn't seem to be needed
anymore. And it breaks the $PATH on the Windows build (AppVeyor CI).
After this change python3 (and 2) is correctly detected on AppVeyor CI.
References #5946
In Windows Lua's os.tmpname() returns relative paths starting with \s,
prepend them with $TEMP to generate a valid path.
In OS X os.tmpname() returns paths in '/tmp' but they should be in
'/private/tmp'. We cannot use os_name() for platform detection because
some tests use tempname() before nvim is spawned, instead use one of the
following:
1. Set SYSTEM_NAME environment variable before calling the tests, it
is set from CMAKE_SYSTEM_NAME(i.e. uname -s or 'Windows')
2. Call uname -s
3. Assume windows
Using /MT was causing issues when building luarocks, revert it, use the
dynammic runtime and generate release DLLs for the dependencies.
Some refactoring was required because for linking cmake looks for the
import libraries (.lib) but on runtime executables we need the .dll files
to be in the same folder.
The DLLs are placed in the bin/ folder in order for nvim.exe to run
during the build and tests. The install target installs the DLLs with
the nvim binary - uses GetPrerequisites to find runtime DLLs.
Some minor issues that required adjustments:
- [MSVC] FindMsgpack.cmake now looks for msgpack_import.lib instead of
msgpack.lib
- The lua-client fails to find libuv.lib, instead it looks for uv.lib,
added second copy of the file to the install command.
- [MSVC] CMAKE_BUILD_TYPE affects the output paths, default to Release.
Part of these changes are credited to @jasonwilliams200OK who fixed the
third-party recipes to consistently use the same build type.
Otherwise, busted may run a different interpreter than the one we
detected, without the capabilities we expect. (For instance, we might
have detected the luajit interpreter, but busted might run the lua
interpreter, without the ffi module.)
By default Neovim searched a Luajit instalation and linked against
the luajit library.
In practice Neovim only requires luajit to run the unit tests. All other
targets only require lua and the correct lua modules. This commit:
1. Remove the strict dependency on Luajit
2. Makes the unittest target depend on the lua 'ffi' module.
If the module is not available the target is not enabled
and a message is displayed.
By default, find_library() searches all directories for one possible
name and then looks for the next name. To make sure we're building
against the same headers and libraries, look for all names in a
directory before moving to the next one.
In 33bc332, version constraints were added to pkg_search_module(), but
that only affects the set of directories searched by
find_library()/find_path().
Once the header directory is found, parse the version from
version_master.h so it can be checked by the find_package() call in the
root CMakeLists.txt.
libmsgpack was the old C++ library provided by msgpack-c. The C library
is libmsgpackc.
The C++ support became header-only, but there was a bug
(msgpack/msgpack-c#395) wherein using msgpack-c's CMake build system
would only install libmsgpack instead of libmsgpackc.
Searching for both libraries, but preferring libmsgpackc, allows for
building against older msgpack-c releases and prepares for the upcoming
msgpack-c release which fixes the aforementioned issues.
Signed-off-by: James McCoy <jamessan@jamessan.com>
When building for X86 the CMake check_library_exists always fails to find
functions from the Win32 API due to name mangling conventions. The convention
for API functions is __stdcall and the CMake test code assumes __cdecl. Since
these are libraries from the Windows API we can simply link against the
libraries without checking for the functions.
