- Use DIRECTORY instead of PATH in get_filename_component
- Use COMPILE_OPTIONS instead of COMPILE_FLAGS. COMPILE_FLAGS is treated
as a single string while COMPILE_OPTIONS is a list, meaning that cmake
will take care of any escaping and quoting automatically.
It's more convenient to not specify the version and let openbsd's
package manager figure it out. This will help us avoid manually bumping
dependency versions when a new version of openbsd is released.
Some packages have multiple versions and not specifying a version in
those cases fails the CI job, so providing a version seems to be
necessary for some key packages.
It's a leftover artifact that currently just acts as an unnecessary
intermediary script that calls the Makefile. It can be replaced by just
calling the Makefile directly.
This will allow cmake to check if any directories needs re-globbing, in
other words, if any new file has been added since last time cmake was
run. This will (allegedly) make the configure stage slower but I have
not noticed any difference so I believe this is well worth it.
FindLua.cmake is a copy from the cmake repo:
https://github.com/Kitware/CMake/blob/0419ecbcad7719614349a07189b45e341a8f2c69/Modules/FindLua.cmake.
It's a cmake module, meaning it's already shipped with cmake by default.
There have been two changes done to our version of FindLua.cmake.
The first change is that
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
was changed to
include(FindPackageHandleStandardArgs.cmake)
This change is required only because we have imported FindLua.cmake
module but not FindPackageHandleStandardArgs module. Had FindLua been
called as a module as intended then this file would not need changing.
The second change is that support for Lua 5.4 is added. However, support
for any version of Lua except for 5.1 is disabled since
https://github.com/neovim/neovim/pull/16633/commits/e322b5c864c771f774ddfea32f6cd5190a1af419.
Because these changes from the upstream FindLua.cmake is unnecessary I
believe we can and should use the builtin FindLua.cmake instead of our
own.
Instead of appending to a command output, append to an existing target
instead. The primary benefit is intermediary ...-cmd targets aren't
needed, we can instead append commands to the relevant target directly.
More specifically, replace exec_program with file(REMOVE ...) so that
the uninstall target is run during the build stage instead of the
configure stage, significantly speeding up the target.
The code snippet that was removed is taken from the cmake FAQ
https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake.
However, this uses undocumented features such as IMMEDIATE when calling
configure_file, which is an artifact from cmake 2.x (it's so old it's
difficult to find information on it). Similarly, this particular code
snippet has been around for a long time and originated from the cmake
mailing lists. Based on this I believe the in-file was a workaround for
the limitations of cmake back then and that it's not required anymore.
The size of long varies depending on architecture, in contrast to the
MAXLNUM constant which sets the maximum allowable number of lines to
2^32-1. This discrepancy may lead to hard to detect bugs, for example
https://github.com/neovim/neovim/issues/18454. Setting linenr_T to a
fix maximum size of 2^32-1 will prevent this type of errors in the
future.
Also change the variables `amount` and `amount_after` to be linenr_T
since they're referring to "the line number difference" between two
texts.
When enabling -municode for MSVC the following warning shows up:
"LINK : warning LNK4044: unrecognized option '/municode'; ignored".
This will ensure cleaner logs for the MSVC job.
Uncrustify and clang-format are already both excellent at ordering
includes; this isn't something we need to check for ourselves. Also
remove the section on include order in the dev-style documentation.
This warning is essentially only triggered for ported vim functions.
It's unlikely that we'll refactor vim functions solely based on their
size since it'd mean we'd greatly deviate from vim, which is a high cost
when it comes to importing the vim patches. Thus, this warning only
serves as an annoyance and should be removed.
Uncrustify version 0.75 assumes the macro inside the enum is an enum
element, and thus adds a comma after it. This breaks neovim and makes it
impossible to build it.
When checking the version of the doxygen installed from conda the output
has the following format:
1.9.2 (ee54ebd4f0ad83d9c44f19a459146de64d0ffba2*)
This would cause an error in the "Missing API docs" CI job. This fix
will correctly parse the doxygen version for both stable releases
("1.9.2") as well as the version with the git commit hash attached.
There have been a few instances where developers got confused as to why
their generated documentation differs from the one generated by the CI.
More often than not, the reason is that their doxygen version is older
than 1.9.0, which is the current minimum version. Having a simple
version check will help save future developers avoid this problem.
Add space around arithmetic operators '+' and '-'.
Remove space between back-to-back parentheses, i.e. ')(' vs. ') ('.
Remove space between '((' or '))' of control statements.
Add space between ')' and '{' of control statements.
Remove space between function name and '(' on function declaration.
Collapse empty blocks between '{' and '}'.
Remove newline at the end of the file.
Remove newline between 'enum' and '{'.
Remove newline between '}' and ')' in a function invocation.
Remove newline between '}' and 'while' of 'do' statement.
xstrnsave is a clone of vim_strnsave that uses char* instead of char_u*.
Its purpose short-term is to help reduce the number of casts and for
long-term to replace vim_strnsave as the need to use char_u is
eliminated.
On GitHub Actions it just repeats the summary that is shown just after.
When run outside of GitHub Actions it erroneously shows the summary of
the previous suites.
Dundar Goc