This fixes gcov/coveralls warnings like the following:
Segmentation fault (core dumped)
charset.c.gcno:version '501*', prefer '406*'
Out of memory allocating 33061786568 bytes after a total of 2522648 bytes
http://stackoverflow.com/a/14676272/249642
* Split build steps to utilize the Travis build lifecycle.
* Move shell code from `.travis.yml` into Bash files in `.ci/`,
one file for each step of the Travis build lifecycle.
* Use configuration variables in `.travis.yml` to change
build behavior (e.g. build 32-bit with `BUILD_32BIT=ON`).
* Keep all configuration in environment variables in
`.travis.yml`. In scripts, concatenate environment variables
according to configuration to change to different behavior.
* Add GCC 5 builds for Linux.
* Use Travis's caching feature [1] for third-party dependencies
and pip packages.
* Allow failures MSan, as the errors it reports have to be
fixed first.
Valgrind is still disabled, but can be enabled by setting
`env: VALGRIND=ON` for a job in `.travis.yml`.
[1] http://docs.travis-ci.com/user/caching
* Functional tests fail with SIGPIPE: disable them until we
figure out the exact problem.
* MSan reports some warnings: allow failures for the Travis
build to allow fixing them in individual follow-up PRs.
- As a general rule of thumb one shouldn't use environment variables
for setting configuration options for CMake. The reason for this is
we don't know when CMake will be executed and re-evaluate that variable.
- e.g. If we run cmake a first time with a var set, and then run make on
a second session (with no var) and cmake is called because a
dependency changed, the option would be disabled
- This commit removes the use of environment vars from
src/nvim/CMakeLists.txt entirely
- Removed SKIP_UNITTEST since it could only be used to remove a target
at configuration time (and the target was optional anyway)
- Turned SANITIZE into an option, clang-asan.sh now passes cmake
-DSANITIZE=ON
- Removed SKIP_EXEC since it was disabling a target at configuration time
(not being used)
- As a general rule of thumb one shouldn't use environment variables
for setting configuration options for CMake. The reason for this is
we don't know when CMake will be executed and re-evaluate that variable.
- e.g. If we run cmake a first time with a var set, and then run make on
a second session (with no var) and cmake is called because a
dependency changed, the option would be disabled
- This commit removes the use of environment vars from
src/nvim/CMakeLists.txt entirely
- Removed SKIP_UNITTEST since it could only be used to remove a target
at configuration time (and the target was optional anyway)
- Turned SANITIZE into an option, clang-asan.sh now passes cmake
-DSANITIZE=ON
- Removed SKIP_EXEC since it was disabling a target at configuration time
(not being used)
The --version flag drives Nvim to take a different code path, which is worth
testing. Now we do it in the "gcc" ci target(It will only fail if the exit code
is different than 0)
We use INFO as the default log level, which leaves code inside DLOG macros
unverified(currently it has compilation errors).
Decrease the log level on travis builds for automatic verification in PRs.
Sanity API checks made by the python-client in the api-python travis target were
converted to lua and will now live in this repository. This will simplify
performing breaking changes to the API as it won't be necessary to send parallel
PRs the python-client.
Always check the logs in case of test failures(which would happen when ASAN
finds an error since it will abort Nvim).
Also run the 'oldtest' target from the gcc-32.sh script
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
