These were imported from the v0.3.3 git tag
https://github.com/neovim/libvterm/tree/v0.3.3 and not the latest
commit. This is for compatibility reasons as the libvterm code was
imported from v0.3.3.
There's no "rule" or bad practice or whatever that says we cannot
generate c files. it is is just that we have ~20 generated headers
and ~2 generated sources and there is nothing in these two generated
source files which sets them aparts. Lua bindings are not different from
rpc bindings, and pathdef is not different from versiondef.
So to simplify build logic and ease the future port to build.zig,
streamline the build to only have generated headers, no direct generated
.c files.
Also "nlua_add_api_functions" had its prototype duplicated twice which
defeated the point of having mandatory prototypes (one source of truth).
Problem: The usage of `_BitScanForward64` causes linking to fail on some systems.
Solution: Correctly check if it exists using `check_c_source_compiles`.
Then we can just load metadata in C as a single msgpack blob. Which also
can be used directly as binarly data, instead of first unpacking all the
functions and ui_events metadata to immediately pack it again, which was
a bit of a silly walk (and one extra usecase of `msgpack_rpc_from_object`
which will get yak shaved in the next PR)
This distinction is important for correct dependency management, as the
nvim binary is used to create some runtime files. The nvim binary (and
the target to build it) is thus called `nvim_bin` and the target to
build all of nvim (binary+runtime) is called `nvim`.
Remove `export` pramgas from defs headers as it causes IWYU to believe
that the definitions from the defs headers comes from main header, which
is not what we really want.
- Use `#pragma once` for `cmake.config/config.h.in`
- Remove unused variable `CACHED_GENERATED_DIR`
- Reorganize and sort variables
- Introduce `STYLUA_DIRS` variable to ensure the `formatlua` and
`lintlua-stylua` operates on the same files.
- Adjust variable scope to avoid using hacky directory properties.
- Add more necessary runtime files as test dependencies
Refactor the --version string to remove semicolons. Although semicolons are
present in LINK_OPTIONS, they are not actually included during compilation.
- add EXTERNALPROJECT_OPTIONS variable to main build
- use `REQUIRED` keyword for IWYU.
- remove check_c_compiler_flag checks when `ENABLE_COMPILER_SUGGESTIONS`
is `ON`. If we explicitly enable it then we probably want it to give
an error if it doesn't exist, rather than silently skip it.
- Move dependency interface libraries to their find module and use them
as a pseudo-imported target.
- Remove BUSTED_OUTPUT_TYPE. It's not used and we can reintroduce it
again if something similar is needed.
- Use LINK_OPTIONS intead of LINK_FLAGS when generating the `--version`
output.
Having a dynamically generated string is more maintainable than having
multiple files.
Also add linker flags and any potential LTO flags to the --version
output.
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
regext_bt.c and regexp_nfa.c are inlined into regexp.c instead of
included as a header. This makes developer tools like clang-tidy and
clangd be able to understand the code better.
- silence false warnings on MSVC
- merge `clang-tidy` cmake target into `lintc` and remove the
corresponding make target
- use cmake's built-in endianness detection
Problem: Configure script may not detect xattr correctly
Solution: include sys/xattr instead of attr/xattr,
make Test_write_with_xattr_support() test
xattr feature correctly
This also applies to the Smack security feature, so change the include
and configure script for it as well.
closes: vim/vim#132296de4e58cf2
Problem: No support for writing extended attributes
Solution: Add extended attribute support for linux
It's been a long standing issue, that if you write a file with extended
attributes and backupcopy is set to no, the file will loose the extended
attributes.
So this patch adds support for retrieving the extended attributes and
copying it to the new file. It currently only works on linux, mainly
because I don't know the different APIs for other systems (BSD, MacOSX and
Solaris). On linux, this should be supported since Kernel 2.4 or
something, so this should be pretty safe to use now.
Enable the extended attribute support with normal builds.
I also added it explicitly to the :version output as well as make it
able to check using `:echo has("xattr")`, to have users easily check
that this is available.
In contrast to the similar support for SELINUX and SMACK support (which
also internally uses extended attributes), I have made this a FEAT_XATTR
define, instead of the similar HAVE_XATTR.
Add a test and change CI to include relevant packages so that CI can
test that extended attributes are correctly written.
closes: vim/vim#306closes: vim/vim#13203e085dfda5d
Co-authored-by: Christian Brabandt <cb@256bit.org>
Having the same directory listed multiple times makes the --version
output needlessly complicated to visualize. This deduplication will only
work for cmake version 3.15 and above, which should be the majority of
neovim builds by now. For older cmake versions we default to the
previous behavior of listing duplicate include directories.
This reduces the total number of khash_t instantiations from 22 to 8.
Make the khash internal functions take the size of values as a runtime
parameter. This is abstracted with typesafe Map containers which
are still specialized for both key, value type.
Introduce `Set(key)` type for when there is no value.
Refactor shada.c to use Map/Set instead of khash directly.
This requires `map_ref` operation to be more flexible.
Return pointers to both key and value, plus an indicator for new_item.
As a bonus, `map_key` is now redundant.
Instead of Map(cstr_t, FileMarks), use a pointer map as the FileMarks struct is
humongous.
Make `event_strings` actually work like an intern pool instead of wtf it
was doing before.
The build type specific flags are defined in the variables
CMAKE_C_FLAGS_<CONFIG>, where <CONFIG> can be DEBUG, RELEASE,
RELWITHDEBINFO and MINSIZEREL.
In addition: merge some checks for the same feature into one
test_compile. This reduces the total number of test compiles
which speeds up the cmake configure stage.
When using a multi config generator, CMake generates an output file for
each configuration when using file(GENERATE). When the contents of the
file for each configuration are different, CMake fails. Instead, create
separate files for each configuration and add a build time step to copy
the configuration specific file to the generic path "auto/versiondef.h"
which is included at build time.
file(GENERATE) has surprising behavior as it doesn't allow different
file contents for configurations with the same file name. This results
in an error when building neovim with a multi-config generator. Use a
workaround for now where we set the build type for multi-config
generators to "Unknown".
Any logic involving CMAKE_BUILD_TYPE is automatically broken as it won't
work with multi-config generators. The only exception is if we
explicitly check whether the current generator is single-config as well.
Instead, use generator expressions or cmake variables that allows to set
options for certain build types only such as
INTERPROCEDURAL_OPTIMIZATION_<CONFIG>.
Opt to generate all headers with optimization level O2 with no debug
information for all build types as that is the simplest way to make it
behave the same for all generators.
This value can not be relied on as it doesn't work for
multi-configuration generators. I don't think this undocumented option
is used much, if at all, so I think we should remove it.
