When using the Visual Studio generator don't use get_target_property for
custom command, because it returns unexpanded VS variables (e.g.
$(Configuration)) within the result as part of the LOCATION path.
The single case where this is a problem is for getting the output path for
nvim-test, instead we use a path here.
The Visual Studio cmake generator creates subdirectories inside
the build path for different build configuration. But this breaks some of our
cmake scripts, like the help tags installer, that assume the targets are
built in that location. Updated CMakeLists.txt to remove extra paths.
- Check if MIN_LOG_LEVEL value is a number 0-3, default to
INFO (1) or ignore it in Release mode
- When TRAVIS_CI_BUILD is ON the default is DEBUG (0)
- Add local.mk.example
We use `git describe` to stamp pre-release versions (dev builds). But
`git describe` uses the result of the most-recent tag (the current
_release_ version)--so we must munge it with the _next_ (i.e.
unreleased) version.
Also fix non-git builds: do not invoke git_describe(NVIM_VERSION_MEDIUM)
if we're not in a git tree, else it gets the dummy value
"HEAD-HASH-NOTFOUND".
Example :version output in non-git build:
NVIM 0.1.2-dev
Example :version output in git build:
NVIM v0.1.2-176-g9c3c2b5
Without this compilation fails due to a missing symbol: SRWLOCK in libuv
headers. _WIN32_WINNT defines the Windows header version that is to be used,
and it seems libuv requires this version. See
b471b33da8
If nvim is built from a non-tagged commit, the truncated commit hash is
already appended to the main version string (e.g., "NVIM v0.1.0-83-g959f260 ..."),
making the "Commit:" field redundant.
Regarding the truncated hash length: we don't have nearly enough commits
to worry about collisions, and probably won't ever, so the default
length should be fine.
When building in a git repo:
- If HEAD corresponds to an annotated tag, (i.e. git_get_exact_tag()
returns truthy) the current build is considered a "release" build:
NVIM_VERSION_MEDIUM is directly assigned the tagged version name,
and NVIM_VERSION_* defines are ignored.
- If HEAD is not a tagged release, then NVIM_VERSION_MEDIUM is
directly assigned the result of `git describe`.
If git (or the repo) is not available:
- The NVIM_VERSION_* defines are used to define NVIM_VERSION_MEDIUM.
Sample outputs for `nvim --version` and `nvim +version`:
Building with git @ non-tagged commit e66df14:
NVIM v0.1.0-1-ge66df14 (compiled Nov 1 2015 19:10:30)
Commit: e66df148f9401be17adab324a6e41d927aae20b3
Building with git @ v0.1.1 tag:
NVIM v0.1.1 (compiled Nov 1 2015 19:03:52)
[no "Commit:" line]
Building this commit _not_ in a git repo:
NVIM 0.1.0-dev (compiled Nov 1 2015 19:16:11)
[no "Commit:" line]
Before this change, building Neovim would recursively search parent
directories for a .git directory. If Neovim was downloaded as a tarball
(i.e. without a .git directory), but placed in a subdirectory of
a Git repository, this caused a CMake error. Such a situation could
occur when packaging Neovim, for example.
Unfortunately, the previous attempt in #3317 did not fix this problem.
* Hide commit information from --version if we can't find any (e.g. when
building from tarball).
To define a release in CMake, set NVIM_VERSION_PRERELEASE to "".
This will modify --version output to:
* Show annotated Git tag instead of commit hash (NVIM_VERSION_COMMIT).
* Hide commit date (NVIM_VERSION_BUILD).
Introduce new build type Dev that replaces RelWithDebInfo for development
builds off master and has optimizations, debug info, and logging enabled.
Keep assertions enabled for RelWithDebInfo.
If downloading Neovim as a tarball (i.e. without Git data),
building Neovim will search parent directories for a .git directory.
Explicitly set GIT_DIR to the project directory to avoid that.
- There are some differences between stdio (*printf) functions in POSIX
and the MS runtime, this commit enables Mingw compatibility for these
functions
`nvim-[lang].1`:
The non-english manuals are completely outdated and still written in
roff, as opposed to mdoc, which is used for `nvim.1`.
Given that, they're nearly useless at the moment, and when/if they are
updated, they should probably be rewritten from scratch using `nvim.1`
as a reference.
`xxd*.1`:
xxd hasn't been in the source tree for a long time, so the manual is of
little use.
`nvimtutor*.1`:
The vimtutor script hasn't ever shipped with nvim, and the consensus
seems to be that it won't, at least in the form of an executable
installed alongside `$(PREFIX)/bin/nvim` (see #2700).
In `nvim.1`, the argument to the `.Os` macro was removed. This was done
because its only purpose was to signify that nvim and nvimtutor
were part of the "Neovim" distribution, i.e., one and the same, which
isn't applicable anymore because `nvimtutor.1` is being removed.
From the `.Os` documentation in `man mdoc`:
Os
Operating system version for display in the page footer. This is the
mandatory third macro of any mdoc file. Its syntax is as follows:
.Os [system [version]]
The optional system parameter specifies the relevant operating system or
environment. It is suggested to leave it unspecified, in which case
mandoc(1) uses its -Ios argument or, if that isn't specified either,
sysname and release as returned by uname(3).
Examples:
.Os
.Os KTH/CSC/TCS
.Os BSD 4.3
See also Dd and Dt.
Reviewed-by: Felipe Morales <hel.sheep@gmail.com>
Reviewed-by: Florian Walch <florian@fwalch.com>
Reviewed-by: Justin M. Keyes <justinkz@gmail.com>
[ci skip]
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>
