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.
Replace old-school cmake with the so-called "Modern CMake", meaning
preferring using targets and properties over directory settings and
variables. This allows greater flexibility, robustness and clarity over
how the code works.
The following deprecated commands will be replaced with their modern
alternatives that operates on a specific target, rather than all targets
in the current directory:
- add_compile_options -> target_compile_options
- include_directories -> target_include_directories
- link_libraries -> target_link_libraries
- add_definitions -> target_compile_definitions
There are mainly four main targets that we currently use: nvim, libnvim,
nvim-test (used by unittests) and ${texe} (used by
check-single-includes). The goal is to explicitly define the
dependencies of each target fully, rather than having everything be
dependent on everything else.
Problem: With a long running Vim the temp directory might be cleared on
some systems.
Solution: Lock the temp directory. (closesvim/vim#6044)
b2d0e51366
This was previously disabled due to build issues on windows.
Any reasonable platform can now be expected to have the necessary
interfaces to build and run the TUI subsystem.
Runtime quality issues of using the TUI (on any new platform) are not
relevant here. Just run Nvim in an external UI instead of the TUI as always.
Problem: Some source files are too big.
Solution: Move buffer and window related functions to evalbuffer.c and
evalwindow.c. (Yegappan Lakshmanan, closesvim/vim#4898)
261f346f81
Allow Include What You Use to remove unnecessary includes and only
include what is necessary. This helps with reducing compilation times
and makes it easier to visualise which dependencies are actually
required.
Work on https://github.com/neovim/neovim/issues/549, but doesn't close
it since this only works fully for .c files and not headers.
Problem:
Dirs "config", "packaging", and "third-party" are all closely related
but this is not obvious from the layout. This adds friction for new
contributors.
Solution:
- rename config/ to cmake.config/
- rename test/config/ to test/cmakeconfig/ because it is used in Lua
tests: require('test.cmakeconfig.paths').
- rename packaging/ to cmake.packaging/
- rename third-party/ to cmake.deps/ (parallel with .deps/)
