When checking code with check_c_source_compiles, the "check variable"
(for the _FORTIFY_SOURCE detection: previously _FORTIFY_SOURCE_ACCEPTABLE, now
HAS_ACCEPTABLE_FORTIFY) is passed to the compiler like
-D_FORTIFY_SOURCE_ACCEPTABLE. This throws off hardening-wrapper [1],
which then NOT sets _FORTIFY_SOURCE=2 for the check, assuming it had already
been set manually as it detected -D_FORTIFY_SOURCE*. Renaming the "check
variable" to not match this pattern works around this problem.
[1] https://github.com/thestinger/hardening-wrapper
Resolves#2632. This is done so C helper modules don't generate unexpected
coverage output.
Reviewed-by: Justin M. Keyes <justinkz@gmail.com>
Reviewed-by: Florian Walch <florian@fwalch.com>
For now, only install man pages matching "nvim*.1": we don't want to
install xxd.1 as it might conflict with that of a user's Vim
installation.
closes#1826
Reviewed-by: Florian Walch <florian@fwalch.com>
Helped-by: John Szakmeister <john@szakmeister.net>
This will help make sure that we build all the right prereqs before
manually running tests under QuickBuild.
Notice that shell-test has been added as a prereq for the functional
tests, since it's a requirement for testing the terminal features.
Old behaviour: termopen('cmd') would run `&shell &shcf "cmd"`, which
caused the functional tests to fail on some systems due to the process
not "owning" the terminal. Also, it is inconsistent with jobstart().
Modify termopen() so that &shell is not invoked, but maintain the old
behaviour with :terminal. Factor the common code for building the
argument vector from jobstart() and modify the functional tests to call
termopen() instead of :terminal (fixes#2354).
Also:
* Add a 'name' option for termopen() so that `:terminal {cmd}` produces
a buffer named "term//{cwd}/{cmd}" and termopen() users can customize
the name.
* Update the documentation.
* Add functional tests for `:terminal` sinse its behaviour now differs
from termopen(). Add "test/functional/fixtures/shell-test.c" and move
"test/functional/job/tty-test.c" there, too.
Helped-by: Justin M. Keyes <@justinmk>
* Set JEMALLOC_NO_DEMANGLE to be able to use `je_*` functions,
regardless of how jemalloc was compiled (--with-jemalloc-prefix)
* Show jemalloc information in Neovim's version output.
Resolve#2449.
For built-in dependencies, shared libraries are removed and static
linking is always used.
For systemwide dependencies, static linking should not be used.
Jemalloc will be used if the cmake option `USE_JEMALLOC` is enabled(which is the
default). To avoid trouble with clang's ASAN, it is disabled by default if the
`SANITIZE` option is enabled.
Since jemalloc has thread cache for small objects, it fills the gap created by
removing klib memory pools.
The `xstrdup` funciton(memory.c) had to be reimplemented on top of `xmalloc` to
make it work with a custom allocator.
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>
Get prefix to a -D_FORTIFY_SOURCE string if it is present in
CFLAGS and apply the prefix to flags added to redefine
_FORTIFY_SOURCE in CFLAGS and CPPFLAGS
* fixes 1569
It turns out the check was being performed without optimizations enabled
even when the CMAKE_BUILD_TYPE was set to a release build. This led to
_FORTIFY_SOURCE's level not being correctly determined, and us failing
to apply the correct workaround.
To counter this, we'll take the default flags for the build type and
apply them. Also, if options are passed via CFLAGS, they are
automatically passed on to the underlying build. So this should cover
all the necessary ground.
This fixes#1647.
- Caller can override bundled dependency location using
DEPS_PREFIX
- Cache variable DEPS_PREFIX, using .deps/usr by default
- Removed unused variables DEPS_BIN_DIR, DEPS_BUILD_DIR, DEPS_DIR
DEPS_INSTALL_DIR
- Corner case: if the caller tries to override DEPS_PREFIX after a
successful cmake configuration, the caller needs to clear the cache
because dependency checks are based on the old value
Some builds don't use Release (such as Gentoo, though it can be told
to). So let's go a bit further and probe the compiler to see if we need
to turn down the _FORTIFY_SOURCE level.
- If possble try to abstract away from Make, and use cmake --build
- third-party still needs to find Make to build some components
- Removed search for Make from CMakeLists.txt
* for CMake < 3.0 --build has no color output
Fixes#1447. `CMAKE_MODULE_PATH` is meant to be a list of directories,
and as such, is not the proper way to launch our scripts. Let's use
`${PROJECT_SOURCE_DIR}/cmake` instead. Also, let's not outright set
`CMAKE_MODULE_PATH`, but instead append our location to the list.
Commit a1d411f9c9 just assumes that gcc
will support the `-Og` option, but gcc that comes with Ubuntu 12.04 does
not. Let's check to see if the flag is supported, and then decide
whether to enable it or not.
Unfortunately, we can't force the specific inclusion of a header file.
So if anything add /opt/local/include to the include path--such as
libintl--then other dependencies might be drawn from /opt/local at
compile time, even though we detected them elsewhere at configure time.
This, in turn, causes issues with mixed versions, such as the iconv.h
header being pulled from /opt/local/include, but linked against the
library in /usr/lib--which can be mismatched versions.
So, despite CMake's best effort to treat /sw and /opt/local as just
another system area, we really need to give them preferential treatment.
To do this, we add them to CMAKE_PREFIX_PATH.
This fixes an issue discovered while re-enabling iconv in #1370.
The -O3 optimization level can often lead to dangerous (and sometimes
incorrect) optimizations being performed. So let's use a level that's
more stable.
If you aren't just building everything into build/, then the functional
tests fail because they can't find the nvim executable. Let's pass in
the location of the nvim executable, and set NVIM_PRG environment
variable accordingly.
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.
Now that the lua client is available, python/lupa are no longer necessary to run
the functional tests. The helper functions previously defined in
run-functional-tests.py were adapted to test/functional/helpers.lua.
- cmake: git_timestamp() returns last commit time formatted as
`YYYYMMddHHmm`.
- Always include commit hash in :version and --version output.
`nvim --version` sample output:
NVIM 0.0.0-alpha+201410070245 (compiled Oct 7 2014 05:30:45)
Commit: f747b2b1ff7bfe7eb00cc2be82d7af87c98f1111
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
The install() command will create the parent directories, but it does so
with the user's umask. We want to do our best to make sure the correct
permissions are being set, without clobbering existing permissions.
To do this, this commit introduces an install_helper(), which is similar
in signature to the install() command, to help ensure that directories
are created ahead of the actual install() command. This will attempt to
use 0644 permissions for files and 0755 permissions for directories by
default--though they can be overridden.
To make this work correctly, without trying to introduce some mechanism
with setting the umask, it meant that there's a small portion that makes
use of an "internal" version of the file() command. It has been tested
on CMake 2.8.11, 2.8.12, and 3.0.2, and works correctly on all versions.
This fixes#1201 and #1086.
