Lesser form of include-what-you-use: at least guarantees that header
file did not forget to include something through some other included
file.
Activate run_single_includes_tests on CI.
Fix some IWYU violations.
References #5321
- Do not exclude any directories from `find` search, remove dumps before tests
instead.
- Install `apport` on travis so that linux tests should produce core dumps
(based on information from travis-ci/travis-ci#3754, not sure whether it still
applies).
- Check cores in lua so that one has an idea which test is failing exactly. Do
this only 10% of time on linux because traversing the file system is slow.
Unit tests are still not touched, though it is what `app` argument in
`check_cores` is for.
TODO? consider using `find`, it may be faster. Consider retiring `os.execute`,
dealing with escaping is bad.
We must invoke src/nvim/testdir/Makefile directly.
Explained in 3d1084f264:
> Running tests from the top-level Makefile will use the third-party
> dependencies from .deps instead of the ones from the Travis cache.
If we could run `oldtest` with CMake, we would not need to do this. Need
USES_TERMINAL feature (CMake 3.2+) for that.
- 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
)
* 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
