As of CMake 3.12, check_include_files() also link the check executable
against the libraries listed in CMAKE_REQUIRED_LIBRARIES. Therefore we
should unset the CMAKE_REQUIRED_* variables after each respective use to
avoid them unnecessarily bleeding into other checks.
There's a mix of CXX and C related variables being set/referenced in our
CMake files. Since we only use C, use an explicit language list of "C"
instead of the implicit "C CXX" and replace all uses of CXX variables
with their C counterparts
The Debian hurd-i386 [build] failed (partly) due to -D_GNU_SOURCE not be
defined:
[215/286] /usr/bin/cc -DINCLUDE_GENERATED_DECLARATIONS -Iconfig -I../src -Isrc/nvim/auto -Iinclude -I/usr/include/luajit-2.1 -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DDISABLE_LOG -Wdate-time -D_FORTIFY_SOURCE=2 -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -O2 -g -DMIN_LOG_LEVEL=3 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -Wno-array-bounds -MD -MT src/nvim/CMakeFiles/nvim.dir/os/pty_process_unix.c.o -MF src/nvim/CMakeFiles/nvim.dir/os/pty_process_unix.c.o.d -o src/nvim/CMakeFiles/nvim.dir/os/pty_process_unix.c.o -c ../src/nvim/os/pty_process_unix.c
../src/nvim/os/pty_process_unix.c: In function 'pty_process_tty_name':
../src/nvim/os/pty_process_unix.c:121:10: warning: implicit declaration of function 'ptsname'; did you mean 'ttyname'? [-Wimplicit-function-declaration]
return ptsname(ptyproc->tty_fd);
Hurd is obviously not Linux, but it is using a GNU compiler and glibc so
it needs -D_GNU_SOURCE for the ptsname() definition to be visible.
[build]: https://buildd.debian.org/status/fetch.php?pkg=neovim&arch=hurd-i386&ver=0.3.0-2&stamp=1528981349&raw=0
Enabling CMake's USE_FOLDERS option and adding the FOLDER property to
targets allows some IDEs to list the targets in an organized
hierarchy of folders.
Environment variables are used to detect when the project is being built
from within Clion or Visual Studio, so that the build process can be
simplified by automatically building the bundled dependencies for them.
"Always use `find_package` with `REQUIRED`."
- We make an exception for LuaJit (not REQUIRED): the `nvim-test` target
is included only if we can find LuaJit.
This is partially a cargo-cult (reference below), but it uncovered at
least one problem: `find_package(LibIntl REQUIRED)` fails on my vanilla
ubuntu 16.04 system.
ref: https://schneide.blog/2017/11/06/4-tips-for-better-cmake/
> optional dependencies is nice, but skipping on REQUIRED is not the way
> you want to do it. In the worst case, some of your features will just
> not work if those packages are not found, with no explanation
> whatsoever. Instead, use explicit feature-toggles (e.g. using option())
> that either skip the find_package call or use it with REQUIRED, so the
> user will know that another lib is needed for this feature.
Prior to CMake 2.8.12, generator expressions could only be used in
custom commands so the path to libnvim-test in test/config/paths.lua was
set by inspecting the target's LOCATION property. Post 2.8.12, the
file(GENERATE) command exists to handle this, but it can't interpolate
normal CMake variables.
In order to bridge the gap while < 2.8.12 is supported, use
configure_file() to create paths.lua.gen with the
$<TARGET_FILE:nvim-test> generator expression and then generate the
final paths.lua file.
Closes#7077
New logging is guarded by cmake LOG_LIST_ACTIONS define. To make it more
efficient it is allocated as a linked list with chunks of length
2^(7+chunk_num); that uses basically the same idea as behind increasing kvec
length (make appending O(1) (amortized)), but reduces constant by not bothering
to move memory around what realloc() would surely do: it is not like we need
random access to log entries here to justify usage of a single continuous memory
block.
closes#7283
regression by 42d892913d
- Don't need to explicitly put "-O2 -g" in RelWithDebInfo; CMake does
that already. That was left-over from 42d892913d which removed the
"Dev" custom build-type, but repurposed the logic for RelWithDebInfo.
- `if(DEFINED MIN_LOG_LEVEL)` doesn't work.
- `if(${MIN_LOG_LEVEL} MATCHES "^$")` doesn't work if -DMIN_LOG_LEVEL is
omitted.
- `if(MIN_LOG_LEVEL)` also isn't what we want: it would be true if
MIN_LOG_LEVEL=0.
As of unibilium 1.2.1, directly manipulating unibi_var_t is deprecated.
../src/nvim/tui/tui.c: In function 'update_attrs':
../src/nvim/tui/tui.c:321:7: warning: 'i' is deprecated: use unibi_var_from_num or unibi_num_from_var instead [-Wdeprecated-declarations]
data->params[0].i = (fg >> 16) & 0xff; // red
^~~~
In file included from ../src/nvim/tui/tui.c:12:0:
/usr/include/unibilium.h:632:9: note: declared here
int i UNIBI_DEPRECATED("use unibi_var_from_num or unibi_num_from_var instead");
^
All use should go through unibi_{num,str}_from_var and
unibi_var_from_{num,str}. Wrap access of unibi_var_t behind a new
UNIBI_SET_NUM_VAR macro which uses the new functions when they're
available.
Handling of process exit is still broken. It detects the moment when the
child process exits, then quickly stops polling for process output. It
should continue polling for output until the agent has scraped all of the
process' output. This problem is easy to notice by running a command like
"dir && exit", but even typing "exit<ENTER>" can manifest the problem --
the "t" might not appear.
winpty's Cygwin adapter handles shutdown by waiting for the agent to close
the CONOUT pipe, which it does after it has scraped the child's last
output. AFAIK, neovim doesn't do anything interesting when winpty closes
the CONOUT pipe.
The main purpose of this build-type was to avoid unwanted ~/.nvimlog
files (which could get really big, and also affects performance) for
non-devs. But that is no longer necessary since the log system now
avoids non-critical logging by default (#6827).
This essentially reverts 87e5a41316
- Establish ERROR log level as "critical". Such errors are rare and will
be valuable when users encounter unusual circumstances.
- Set -DMIN_LOG_LEVEL=3 for release-type builds
