- 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
)
We use a Makefile which in turn uses cmake. If we wanted to set the install
prefix for cmake, we had to do this so far:
make CMAKE_FLAGS="-DCMAKE_INSTALL_PREFIX=/tmp/nvim"
That's long and hard to remember. Following the conventions of other Makefiles,
this now works as well and is equivalent:
make PREFIX=/tmp/nvim
Specify that the ${GENERATED_HELP_TAGS} "command" (output) depends on
`helptags` so that it always regenerates the doc/ tags. (cmake "targets"
always run, whereas "commands" are contingent on their dependencies. But
we don't define doc/ dependencies because they are circular.)
refs https://github.com/neovim/neovim/pull/2124#discussion_r26107174
Unlike Travis, `make test` currently only runs functional tests.
This can cause confusion since one might (understandably) think that `make
test` runs unit tests too, which it doesn't.
The `oldtest` target is still left out because it's quite slow and
Travis already runs it.
Problem: With some regexp patterns the NFA engine uses many states and
becomes very slow. To the user it looks like Vim freezes.
Solution: When the number of states reaches a limit fall back to the old
engine. (Christian Brabandt)
https://github.com/vim/vim/releases/tag/v7-4-497
Helped-by: David Bürgin <676c7473@gmail.com>
Helped-by: Justin M. Keyes <justinkz@gmail.com>
Helped-by: Scott Prager <splinterofchaos@gmail.com>
- third-party is built under .deps by default instead of using its own
${CMAKE_BINARY_DIR}, move this default setting out of the cmake
settings and into the Makefile.
- As a consequence the workflow of building third-party using CMake
should feel more natural, avoid the additional folder or setting
DEPS_DIR from the command line.
- This commit does not change the default behaviour when calling the
Makefile wrapper.
Remove build warning:
The target name "test" is reserved or not valid for certain CMake
features, such as generator expressions, and may result in undefined
behavior.
The 'lupa' python package provides a simple way to seamless integrate lua and
python code.
This commit replaces vroom by a python script that exposes the 'neovim' package
to a lua state, and invokes busted to run functional tests. This is a temporary
solution that will enable writing functional tests using lua/bused while a lua
client library is not available.
The reason for dropping vroom is flexibility: Lua/busted has a nice DSL-style
syntax while also providing the customization power of a full programming
language. Another reason is to use a single framework for unit/functional tests.
Two other changes were performed in this commit:
- Instead of "gcc-unittest/gcc-ia32", the travis builds for gcc are now
identified by "gcc/gcc-32". They will run unit/functional tests for both 64
and 32 bits.
- Old integration tests(in src/nvim/testdir) are now ran by the 'oldtest' target
- Leave src as include dir (for includes to recognize 'nvim/' prefix).
- Change subdirectory from src to src/nvim.
- Fix msgpack generation.
- Fix some other paths to new locations.
This achieves several goals:
* Less reliance on scripts so we have better portability to Windows
(though we still have a ways to go for proper Windows support).
Luajit, luarocks, moonscript, and busted are all installed via CMake
now.
* Trying to make use of pkg-config to get the correct libraries. The
latest libuv is still broken in this regard, but we'll at least be in
a position to use it.
* Allow the use of Ninja or make. The former runs faster in many
environments, and automatically makes use of parallel builds.
This also allows for system installed dependencies--though not through
the Makefile just yet--and adds support for FreeBSD.
This also make us build libuv and luajit as static libraries only, since
we're only concerned about having static libraries for our bundled
dependencies.
Include a new SINGLE_MAKE which can be used to invoke make but using
only a single job, and in way that avoids any warnings from make.
Use SINGLE_MAKE to execute the tests, since they're meant to be run
serially.
Also, prefer the use of $(MAKE) to avoid invoking an extra subshell
(saves some time).
Tests will be written using the [moonscript](http://moonscript.org/) language,
a lua 'dialect' that is whitespace-significant and has a syntax similar to
coffeescript. The test framework used is [busted](http://olivinelabs.com/busted/),
a bdd framework for lua/moonscript.
Luajit has a nice ffi module, which lets lua programs link shared libraries and
call it's functions without writing any C code.
To take advantage of this fact for testing C functions, a new target was added
to CMakeLists.txt, which compiles neovim as a shared library that is loaded by
the process running the tests.
This commit adds necessary code for downloading and installing a lua package
manager(luarocks) locally. It wasn't added as a subtree because there are quite
a few blobs in its source tree.
Change an explicit ``cd build && make`` into the more usual
``${MAKE} -C build`` style of invoking make in a subdirectory. This
should mean that ``make -jN`` from the top-level Makefile should work.
Closes#162.
The CMake prefix path is the set of directories CMake searches for
libraries, header files, etc. Use the .deps directory we create when
building libuv as one of those locations.
Although CMAKE_FLAGS was already a Makefile variable, it didn't have an
empty default value meaning that extending the flags to CMake in a clean
way was difficult. Add a CMAKE_EXTRA_FLAGS variable which is appended to
the default flags.
This simply calls the install target in the build directory. IMHO I
think it's looking a bit hacky having a separate Makefile target to do
this rather than using the usual CMake workflow but mine is not to
reason why... [Also, I've copied ``cd build && make ...`` although I'm
sure ``$MAKE -C build/ ...`` is probably the Right Thing (TM).]
Note that you'll have to set CMAKE_INSTALL_PREFIX on the cmake command
line to change where this installs to.
