kevin/neovim
1
Fork 0
mirror of https://github.com/neovim/neovim.git synced 2024-12-24 13:15:09 -07:00
Code Issues Packages Projects Releases Wiki Activity
1e37703a74
neovim/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

315 lines
10 KiB
CMake
Raw Normal View History

doc: job/channel, misc #7783 doc: termios defaults. ref #6992 doc: :help shell-powershell doc: provider: Python minimum version is 2.7, 3.4 doc: remove :!start special-case. #5844 doc: mention #7917 change which accepts empty Array for Dictionary parameter doc: <Cmd> pseudokey doc: lmap change #5658 doc: -s, -es
2017-12-27 11:30:23 -07:00
# CMAKE REFERENCE
# intro: https://codingnest.com/basic-cmake/
# best practices (3.0+): https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
docs: various #12823 - increase python line-length limit from 88 => 100. - gen_help_html: fix bug in "tag" case (tbl_count => tbl_contains) ref #15632 fix #18215 fix #18479 fix #20527 fix #20532 Co-authored-by: Ben Weedon <ben@weedon.email>
2022-10-09 05:21:52 -07:00
# pitfalls: https://izzys.casa/2019/02/everything-you-never-wanted-to-know-about-cmake/
doc: job/channel, misc #7783 doc: termios defaults. ref #6992 doc: :help shell-powershell doc: provider: Python minimum version is 2.7, 3.4 doc: remove :!start special-case. #5844 doc: mention #7917 change which accepts empty Array for Dictionary parameter doc: <Cmd> pseudokey doc: lmap change #5658 doc: -s, -es
2017-12-27 11:30:23 -07:00
ci: split ci.yml into a test workflow and a build test workflow (#22302) Having a workflow that only builds neovim without running all of the tests is a cheap way to test the build still works without burning too much CI time.
2023-02-18 02:47:22 -07:00
# Version should match the tested CMAKE_URL in .github/workflows/build.yml.
build: update cmake min version to 3.10 #16065 * build(cmake): update cmake min version to 3.10 * ci: test cmake minimum required version * build(cmake): remove some legacy includes * Since version 3.5 cmake_parse_arguments is implemented natively.
2021-10-19 19:19:33 -07:00
cmake_minimum_required(VERSION 3.10)
ci(windows): treat compiler warnings as errors Reduce the warning level from 3 to 1 and fix all warnings.
2022-11-12 05:34:14 -07:00
# Can be removed once minimum version is at least 3.15
if(POLICY CMP0092)
cmake_policy(SET CMP0092 NEW)
endif()
cmake: Explicitly declare C as the project language 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
2018-06-15 05:33:07 -07:00
project(nvim C)
Import vim from changeset v5628:c9cad40b4181 - Cleanup source tree, leaving only files necessary for compilation/testing - Process files through unifdef to remove tons of FEAT_* macros - Process files through uncrustify to normalize source code formatting. - Port the build system to cmake
2014-01-31 06:39:15 -07:00
build(cmake): fix policy warning
2022-03-03 04:20:21 -07:00
if(POLICY CMP0075)
cmake_policy(SET CMP0075 NEW)
endif()
build: get rid of warnings with `cmake --debug-output` (#11131)
2019-10-01 18:44:57 -07:00
add custom CMake module path
2014-02-24 13:54:45 -07:00
# Point CMake at any custom modules we may ship
build: fix CMAKE_MODULE_PATH usage Fixes #1447. `CMAKE_MODULE_PATH` is meant to be a list of directories, and as such, is not the proper way to launch our scripts. Let's use `${PROJECT_SOURCE_DIR}/cmake` instead. Also, let's not outright set `CMAKE_MODULE_PATH`, but instead append our location to the list.
2014-11-10 17:26:01 -07:00
list(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake")
add custom CMake module path
2014-02-24 13:54:45 -07:00
build: use modern cmake (#21589) 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.
2023-01-10 10:49:57 -07:00
include(CheckCCompilerFlag)
include(CheckCSourceCompiles)
include(InstallHelpers)
include(LuaHelpers) # Find Lua interpreter
build: prevent in-tree builds for the time being, as it's not supported
2016-10-11 15:35:02 -07:00
include(PreventInTreeBuilds)
feat(build): add_glob_target runs only on changed files #19070 The general idea is that add_glob_targets creates a "touch file", a dummy file that acts as a dependency in order to check which files are outdated since the last time the target was run. Remove RunUncrustify.cmake as it's no longer necessary. It was initially introduced to silence its noisy output. The per-file targets will suppress the noisy output from uncrustify, except for the very first run. Also remove DefCmdTarget.cmake since add_glob_target already incorporates its functionality.
2022-06-30 05:10:05 -07:00
include(Util)
set(TOUCHES_DIR ${PROJECT_BINARY_DIR}/touches)
build: prevent in-tree builds for the time being, as it's not supported
2016-10-11 15:35:02 -07:00
cmake: Organize targets into folders 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.
2018-06-17 05:54:39 -07:00
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
build: enable ccache project-wide (#22045) Currently, only the nvim target uses ccache but not libnvim or unittests. It is generally a good idea to operate on targets rather than globally, but this is an exception as there isn't a target where we don't want to use ccache on.
2023-01-29 09:02:34 -07:00
find_program(CCACHE_PRG ccache)
if(CCACHE_PRG)
set(CMAKE_C_COMPILER_LAUNCHER ${CMAKE_COMMAND} -E env CCACHE_SLOPPINESS=pch_defines,time_macros ${CCACHE_PRG})
endif()
Revamp the build system. This achieves several goals: * Less reliance on scripts so we have better portability to Windows (though we still have a ways to go for proper Windows support). Luajit, luarocks, moonscript, and busted are all installed via CMake now. * Trying to make use of pkg-config to get the correct libraries. The latest libuv is still broken in this regard, but we'll at least be in a position to use it. * Allow the use of Ninja or make. The former runs faster in many environments, and automatically makes use of parallel builds. This also allows for system installed dependencies--though not through the Makefile just yet--and adds support for FreeBSD. This also make us build libuv and luajit as static libraries only, since we're only concerned about having static libraries for our bundled dependencies.
2014-03-03 08:09:06 -07:00
# Prefer our bundled versions of dependencies.
build: respect $DEPS_BUILD_DIR Without this, the CI_TARGET=lint travis job cant't find the cached deps (in $HOME/nvim-deps), nor can it update the cache.
2018-03-11 05:15:42 -07:00
if(DEFINED ENV{DEPS_BUILD_DIR})
build: remove pkgconfig-related code (#22422) Cmake should already be able to find everything on its own.
2023-02-26 14:32:08 -07:00
set(DEPS_PREFIX "$ENV{DEPS_BUILD_DIR}/usr" CACHE PATH "Path prefix for finding dependencies")
build: respect $DEPS_BUILD_DIR Without this, the CI_TARGET=lint travis job cant't find the cached deps (in $HOME/nvim-deps), nor can it update the cache.
2018-03-11 05:15:42 -07:00
else()
build: remove pkgconfig-related code (#22422) Cmake should already be able to find everything on its own.
2023-02-26 14:32:08 -07:00
set(DEPS_PREFIX "${CMAKE_CURRENT_SOURCE_DIR}/.deps/usr" CACHE PATH "Path prefix for finding dependencies")
deps: Build bundled dependencies automatically for IDEs 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.
2018-06-10 07:57:12 -07:00
# When running from within CLion or Visual Studio,
# build bundled dependencies automatically.
if(NOT EXISTS ${DEPS_PREFIX}
AND (DEFINED ENV{CLION_IDE}
OR DEFINED ENV{VisualStudioEdition}))
message(STATUS "Building dependencies...")
set(DEPS_BUILD_DIR ${PROJECT_BINARY_DIR}/.deps)
file(MAKE_DIRECTORY ${DEPS_BUILD_DIR})
execute_process(
COMMAND ${CMAKE_COMMAND} -G ${CMAKE_GENERATOR}
build: prefer -D <variable>=<value> over -D<variable>=<value> (#22164) This makes it easier to see that -D is referring to the entire "<variable>=<value>", rather than only <variable>. It also help syntax highlighters highlight built-in variables.
2023-02-08 03:00:16 -07:00
-D CMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
-D CMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-D CMAKE_C_COMPILER=${CMAKE_C_COMPILER}
-D CMAKE_C_FLAGS=${CMAKE_C_FLAGS}
-D CMAKE_C_FLAGS_DEBUG=${CMAKE_C_FLAGS_DEBUG}
-D CMAKE_C_FLAGS_MINSIZEREL=${CMAKE_C_FLAGS_MINSIZEREL}
-D CMAKE_C_FLAGS_RELWITHDEBINFO=${CMAKE_C_FLAGS_RELWITHDEBINFO}
-D CMAKE_C_FLAGS_RELEASE=${CMAKE_C_FLAGS_RELEASE}
-D CMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
build: rename build-related dirs 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/)
2022-06-27 03:08:59 -07:00
${PROJECT_SOURCE_DIR}/cmake.deps
deps: Build bundled dependencies automatically for IDEs 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.
2018-06-10 07:57:12 -07:00
WORKING_DIRECTORY ${DEPS_BUILD_DIR})
execute_process(
COMMAND ${CMAKE_COMMAND} --build ${DEPS_BUILD_DIR}
--config ${CMAKE_BUILD_TYPE})
set(DEPS_PREFIX ${DEPS_BUILD_DIR}/usr)
endif()
build: respect $DEPS_BUILD_DIR Without this, the CI_TARGET=lint travis job cant't find the cached deps (in $HOME/nvim-deps), nor can it update the cache.
2018-03-11 05:15:42 -07:00
endif()
deps: Build bundled dependencies automatically for IDEs 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.
2018-06-10 07:57:12 -07:00
build: remove CMAKE_CROSSCOMPILING code #18914 This is rarely, if ever, used and certainly not tested. It's likely this isn't functional anymore.
2022-06-12 15:11:14 -07:00
list(INSERT CMAKE_PREFIX_PATH 0 ${DEPS_PREFIX})
Revamp the build system. This achieves several goals: * Less reliance on scripts so we have better portability to Windows (though we still have a ways to go for proper Windows support). Luajit, luarocks, moonscript, and busted are all installed via CMake now. * Trying to make use of pkg-config to get the correct libraries. The latest libuv is still broken in this regard, but we'll at least be in a position to use it. * Allow the use of Ninja or make. The former runs faster in many environments, and automatically makes use of parallel builds. This also allows for system installed dependencies--though not through the Makefile just yet--and adds support for FreeBSD. This also make us build libuv and luajit as static libraries only, since we're only concerned about having static libraries for our bundled dependencies.
2014-03-03 08:09:06 -07:00
build: give priority to /sw and /opt/local on Mac OS X Unfortunately, we can't force the specific inclusion of a header file. So if anything add /opt/local/include to the include path--such as libintl--then other dependencies might be drawn from /opt/local at compile time, even though we detected them elsewhere at configure time. This, in turn, causes issues with mixed versions, such as the iconv.h header being pulled from /opt/local/include, but linked against the library in /usr/lib--which can be mismatched versions. So, despite CMake's best effort to treat /sw and /opt/local as just another system area, we really need to give them preferential treatment. To do this, we add them to CMAKE_PREFIX_PATH. This fixes an issue discovered while re-enabling iconv in #1370.
2014-11-08 14:16:39 -07:00
if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
build(macos): use consistent MACOSX_DEPLOYMENT_TARGET (#19430) Use the same logic for both deps (including LuaJIT, for which setting this variable is mandatory) and Nvim: either the eponymous environment variable if set, or the current software version if not. Removes annoying warnings when building locally on macOS.
2022-07-19 07:10:59 -07:00
# If the macOS deployment target is not set manually (via $MACOSX_DEPLOYMENT_TARGET),
# fall back to local system version. Needs to be done both here and in cmake.deps.
if(NOT CMAKE_OSX_DEPLOYMENT_TARGET)
execute_process(COMMAND sw_vers -productVersion
OUTPUT_VARIABLE MACOS_VERSION
OUTPUT_STRIP_TRAILING_WHITESPACE)
set(CMAKE_OSX_DEPLOYMENT_TARGET "${MACOS_VERSION}")
endif()
build: use modern cmake (#21589) 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.
2023-01-10 10:49:57 -07:00
message(STATUS "Using deployment target ${CMAKE_OSX_DEPLOYMENT_TARGET}")
win: Define USE_FNAME_CASE (#5962)
2017-01-17 08:32:41 -07:00
endif()
CMakeLists: enable USE_FNAME_CASE on Mac
2015-03-26 20:30:45 -07:00
win: Define USE_FNAME_CASE (#5962)
2017-01-17 08:32:41 -07:00
if(WIN32 OR CMAKE_SYSTEM_NAME STREQUAL "Darwin")
option: fix problem with fileignorecase not being set properly
2021-02-23 21:54:12 -07:00
# Ignore case when comparing filenames on Windows and Mac.
set(CASE_INSENSITIVE_FILENAME TRUE)
win: Define USE_FNAME_CASE (#5962)
2017-01-17 08:32:41 -07:00
# Enable fixing case-insensitive filenames for Windows and Mac.
CMakeLists: enable USE_FNAME_CASE on Mac
2015-03-26 20:30:45 -07:00
set(USE_FNAME_CASE TRUE)
build: give priority to /sw and /opt/local on Mac OS X Unfortunately, we can't force the specific inclusion of a header file. So if anything add /opt/local/include to the include path--such as libintl--then other dependencies might be drawn from /opt/local at compile time, even though we detected them elsewhere at configure time. This, in turn, causes issues with mixed versions, such as the iconv.h header being pulled from /opt/local/include, but linked against the library in /usr/lib--which can be mismatched versions. So, despite CMake's best effort to treat /sw and /opt/local as just another system area, we really need to give them preferential treatment. To do this, we add them to CMAKE_PREFIX_PATH. This fixes an issue discovered while re-enabling iconv in #1370.
2014-11-08 14:16:39 -07:00
endif()
revert: "ci: remove mingw job #18580" This partially reverts commit f8af81445bb48966d54f4a956842d935d009d275. The mingw parts of cmake was removed to see if it was still used (ref: https://github.com/neovim/neovim/pull/18580). It turns out it is, so this will fix that. Closes: https://github.com/neovim/neovim/issues/18597
2022-05-17 06:08:24 -07:00
if (MINGW)
# Disable LTO by default as it may not compile
# See https://github.com/Alexpux/MINGW-packages/issues/3516
# and https://github.com/neovim/neovim/pull/8654#issuecomment-402316672
option(ENABLE_LTO "enable link time optimization" OFF)
else()
option(ENABLE_LTO "enable link time optimization" ON)
endif()
build/CMake: find_package(… REQUIRED) "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.
2018-06-01 11:17:24 -07:00
build/CMakeLists.txt: group related logic - Group CMAKE_BUILD_TYPE-related logic together. - Print the MIN_LOG_LEVEL message (in the build-log) next to the CMAKE_BUILD_TYPE message.
2019-02-15 13:18:16 -07:00
message(STATUS "CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}")
build: consistently set build type regardless of generator or platform #19760 Change the default build type to always be Debug, and allow only four predefined build types: Debug, Release, RelWithDebInfo and MinRelSize. Furthermore, flags meant for single-configuration generator (make, ninja) will not be used for multi-configuration generators (visual studio, Xcode), and flags meant for multi-configuration generators will not be used for single-configuration generators. This will allow Debug builds to be built with MSVC which requires that all dependencies are also built with the Debug build type to avoid runtime library mismatch. The correct way to specify build type (for example Release) for single-configuration generators (Make and Ninja) is to run cmake -B build -D CMAKE_BUILD_TYPE=Release cmake --build build while for multi-configuration generators (Visual Studio, Xcode and Ninja Multi-Config) is to run cmake -B build cmake --build build --config Release Passing CMAKE_BUILD_TYPE for multi-config generators will now not only not be used, but also generate a warning for the user. Co-authored-by: dundargoc <gocundar@gmail.com>
2022-09-06 07:52:39 -07:00
set_default_buildtype()
CMake: Defer setting CACHE CMAKE_BUILD_TYPE. The Visual Studio CMake generator fails to configure if CACHE CMAKE_BUILD_TYPE is set before CMAKE_BUILD_TYPE.
2015-12-19 20:58:47 -07:00
version: semver.org compliance 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
2015-12-13 10:29:02 -07:00
# If not in a git repo (e.g., a tarball) these tokens define the complete
api: api_info()['version'] API level is disconnected from NVIM version. The API metadata holds the current API level, and the lowest backwards-compatible level supported by this instance. Release 0.1.6 is the first release that reports the Nvim version and API level. metadata['version'] = { major: 0, minor: 1, patch: 6, api_level: 1, api_compatible: 0, api_prerelease: false, } The API level may remain unchanged across Nvim releases if the API has not changed. When changing the API, - set NVIM_API_PRERELEASE to true - increment NVIM_API_LEVEL (at most once per Nvim version) - adjust NVIM_API_LEVEL_COMPAT if backwards-compatibility was broken api_level_0.mpack was generated from Nvim 0.1.5 with: nvim --api-info
2016-10-26 06:20:00 -07:00
# version string, else they are combined with the result of `git describe`.
version: report commit hash as "build number" in long version string
2014-10-04 15:32:47 -07:00
set(NVIM_VERSION_MAJOR 0)
version bump
2022-09-30 08:26:25 -07:00
set(NVIM_VERSION_MINOR 9)
version bump
2018-12-30 16:44:49 -07:00
set(NVIM_VERSION_PATCH 0)
version bump
2022-09-30 08:26:25 -07:00
set(NVIM_VERSION_PRERELEASE "-dev") # for package maintainers
version: Prepare for releases. * 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).
2015-09-28 03:17:19 -07:00
api: api_info()['version'] API level is disconnected from NVIM version. The API metadata holds the current API level, and the lowest backwards-compatible level supported by this instance. Release 0.1.6 is the first release that reports the Nvim version and API level. metadata['version'] = { major: 0, minor: 1, patch: 6, api_level: 1, api_compatible: 0, api_prerelease: false, } The API level may remain unchanged across Nvim releases if the API has not changed. When changing the API, - set NVIM_API_PRERELEASE to true - increment NVIM_API_LEVEL (at most once per Nvim version) - adjust NVIM_API_LEVEL_COMPAT if backwards-compatibility was broken api_level_0.mpack was generated from Nvim 0.1.5 with: nvim --api-info
2016-10-26 06:20:00 -07:00
# API level
fix(tui): more work in the TUI
2022-05-02 12:10:01 -07:00
set(NVIM_API_LEVEL 11) # Bump this after any API change.
api: api_info()['version'] API level is disconnected from NVIM version. The API metadata holds the current API level, and the lowest backwards-compatible level supported by this instance. Release 0.1.6 is the first release that reports the Nvim version and API level. metadata['version'] = { major: 0, minor: 1, patch: 6, api_level: 1, api_compatible: 0, api_prerelease: false, } The API level may remain unchanged across Nvim releases if the API has not changed. When changing the API, - set NVIM_API_PRERELEASE to true - increment NVIM_API_LEVEL (at most once per Nvim version) - adjust NVIM_API_LEVEL_COMPAT if backwards-compatibility was broken api_level_0.mpack was generated from Nvim 0.1.5 with: nvim --api-info
2016-10-26 06:20:00 -07:00
set(NVIM_API_LEVEL_COMPAT 0) # Adjust this after a _breaking_ API change.
fix(tui): more work in the TUI
2022-05-02 12:10:01 -07:00
set(NVIM_API_PRERELEASE true)
api: Nvim version, API level #5386 The API level is disconnected from the NVIM version. The API metadata holds the current API level, and the lowest backwards-compatible level supported by this instance. Release 0.1.6 will be the first release reporting the Nvim version and API level. metadata['version'] = { major: 0, minor: 1, patch: 6, prerelease: true, api_level: 1, api_compatible: 0, } The API level may remain unchanged across Neovim releases if the API has not changed. When changing the API the CMake variable NVIM_API_PRERELEASE is set to true, and NVIM_API_CURRENT/NVIM_API_COMPATIBILITY are incremented accordingly. The functional tests check the API table against fixtures of past versions of Neovim. It compares all the functions in the old table with the new one, it does ignore some metadata attributes that do not alter the function signature or were removed since 0.1.5. Currently the only fixture is 0.mpack, generated from Neovim 0.1.5 with nvim --api-info.
2016-09-25 10:46:37 -07:00
build/CMakeLists.txt: group related logic - Group CMAKE_BUILD_TYPE-related logic together. - Print the MIN_LOG_LEVEL message (in the build-log) next to the CMAKE_BUILD_TYPE message.
2019-02-15 13:18:16 -07:00
# Default to -O2 on release builds.
if(CMAKE_C_FLAGS_RELEASE MATCHES "-O3")
message(STATUS "Replacing -O3 in CMAKE_C_FLAGS_RELEASE with -O2")
string(REPLACE "-O3" "-O2" CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE}")
endif()
build: replace deprecated CMAKE_COMPILER_IS_GNUCC variable Instead use the recommended form `CMAKE_C_COMPILER_ID MATCHES "GNU"`
2022-08-26 05:30:55 -07:00
if(CMAKE_C_COMPILER_ID MATCHES "GNU")
cmake: Remove custom "Dev" build-type. (#6932) 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 87e5a4131666e44354f280538cbc6bbe52225092
2017-06-29 00:29:40 -07:00
check_c_compiler_flag(-Og HAS_OG_FLAG)
else()
set(HAS_OG_FLAG 0)
CMake: Add custom Dev build type. 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.
2015-09-28 03:14:38 -07:00
endif()
build: set MIN_LOG_LEVEL correctly (#7419) closes #7283 regression by 42d892913daa215c27e41b2255e96c1ce09ea56c - Don't need to explicitly put "-O2 -g" in RelWithDebInfo; CMake does that already. That was left-over from 42d892913daa2 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.
2017-10-20 17:30:21 -07:00
#
# Build-type: RelWithDebInfo
#
cmake: Remove custom "Dev" build-type. (#6932) 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 87e5a4131666e44354f280538cbc6bbe52225092
2017-06-29 00:29:40 -07:00
if(HAS_OG_FLAG)
build: set MIN_LOG_LEVEL correctly (#7419) closes #7283 regression by 42d892913daa215c27e41b2255e96c1ce09ea56c - Don't need to explicitly put "-O2 -g" in RelWithDebInfo; CMake does that already. That was left-over from 42d892913daa2 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.
2017-10-20 17:30:21 -07:00
set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO} -Og -g")
endif()
# We _want_ assertions in RelWithDebInfo build-type.
if(CMAKE_C_FLAGS_RELWITHDEBINFO MATCHES DNDEBUG)
cmake: Remove custom "Dev" build-type. (#6932) 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 87e5a4131666e44354f280538cbc6bbe52225092
2017-06-29 00:29:40 -07:00
string(REPLACE "-DNDEBUG" "" CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO}")
build(MSVC): enable assertions on RelWithDebInfo build type (#22326)
2023-02-19 07:06:53 -07:00
string(REPLACE "/DNDEBUG" "" CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO}")
CMake: Add custom Dev build type. 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.
2015-09-28 03:14:38 -07:00
endif()
eval/typval: Log list actions 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.
2018-01-02 18:25:42 -07:00
option(LOG_LIST_ACTIONS "Add list actions logging" OFF)
CMake: Add option for Clang TSan, rename option ASAN -> ASAN_UBSAN.
2015-06-09 01:43:22 -07:00
option(CLANG_ASAN_UBSAN "Enable Clang address & undefined behavior sanitizer for nvim binary." OFF)
CMake: Add option for Clang MSan.
2015-06-08 09:49:23 -07:00
option(CLANG_MSAN "Enable Clang memory sanitizer for nvim binary." OFF)
CMake: Add option for Clang TSan, rename option ASAN -> ASAN_UBSAN.
2015-06-09 01:43:22 -07:00
option(CLANG_TSAN "Enable Clang thread sanitizer for nvim binary." OFF)
if((CLANG_ASAN_UBSAN AND CLANG_MSAN)
OR (CLANG_ASAN_UBSAN AND CLANG_TSAN)
OR (CLANG_MSAN AND CLANG_TSAN))
build: adjust some messages (#9087)
2018-10-06 09:45:34 -07:00
message(FATAL_ERROR "Sanitizers cannot be enabled simultaneously")
CMake: Add option for Clang MSan.
2015-06-08 09:49:23 -07:00
endif()
CMake: Add option for Clang TSan, rename option ASAN -> ASAN_UBSAN.
2015-06-09 01:43:22 -07:00
if((CLANG_ASAN_UBSAN OR CLANG_MSAN OR CLANG_TSAN) AND NOT CMAKE_C_COMPILER_ID MATCHES "Clang")
build: adjust some messages (#9087)
2018-10-06 09:45:34 -07:00
message(FATAL_ERROR "Sanitizers are only supported for Clang")
deps: Add jemalloc as an optional dependency 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.
2015-04-12 07:40:08 -07:00
endif()
Fix build output paths for Visual Studio generator 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.
2016-01-08 19:40:57 -07:00
# Place targets in bin/ or lib/ for all build configurations
Revamp the build system. This achieves several goals: * Less reliance on scripts so we have better portability to Windows (though we still have a ways to go for proper Windows support). Luajit, luarocks, moonscript, and busted are all installed via CMake now. * Trying to make use of pkg-config to get the correct libraries. The latest libuv is still broken in this regard, but we'll at least be in a position to use it. * Allow the use of Ninja or make. The former runs faster in many environments, and automatically makes use of parallel builds. This also allows for system installed dependencies--though not through the Makefile just yet--and adds support for FreeBSD. This also make us build libuv and luajit as static libraries only, since we're only concerned about having static libraries for our bundled dependencies.
2014-03-03 08:09:06 -07:00
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
Allow building as a static -fPIC library
2014-11-30 19:22:46 -07:00
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
Fix build output paths for Visual Studio generator 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.
2016-01-08 19:40:57 -07:00
foreach(CFGNAME ${CMAKE_CONFIGURATION_TYPES})
string(TOUPPER ${CFGNAME} CFGNAME)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CFGNAME} ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CFGNAME} ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_${CFGNAME} ${CMAKE_BINARY_DIR}/lib)
endforeach()
Changed binary output directory from src/ to bin/
2014-02-22 08:30:50 -07:00
Update lua client to 0.0.1-24 The new version of the lua client uses libmpack as a backend, and some test scripts had to be updated to reflect that.
2016-04-13 05:21:32 -07:00
set(LUA_DEPENDENCIES lpeg mpack bit)
Check dependencies for each lua interpreter. - When USE_BUNDLED=OFF and the system has multiple lua interpreters (luajit AND lua) it may occur that only the later has the needed dependencies (lua-lpeg, lua-cmsgpack). If we pick luajit then finding the dependencies FAILS. - This commit groups detection of the lua interpreter with the lua dependencies it tries to find them for both the interpreters and choses the first one that has them. Helped-by: John Szakmeister <john@szakmeister.net>
2014-07-11 04:12:18 -07:00
if(NOT LUA_PRG)
CMake: Search all possibly usable Lua executables. (#4858)
2016-06-03 09:21:29 -07:00
foreach(CURRENT_LUA_PRG luajit lua5.1 lua5.2 lua)
cmake: only set LUA_PRG with successful check (#11172) This is relevant for when using `USE_BUNDLED_LUAJIT=ON` with `USE_BUNDLED_LUAROCKS=OFF`, and then building without the necessary modules being installed/activated there yet: it would check the other (system) "lua" interpreters also, and in case all failed keep the `LUA_PRG` in the cache for the last failed entry - making it not re-check the previous ones on the next build (after you might have activated your custom LuaRocks installation). Only setting LUA_PRG if the check was successful handles the case better where it is configured already - we should not try to re-configure it then.
2019-10-07 08:42:40 -07:00
unset(_CHECK_LUA_PRG CACHE)
Check dependencies for each lua interpreter. - When USE_BUNDLED=OFF and the system has multiple lua interpreters (luajit AND lua) it may occur that only the later has the needed dependencies (lua-lpeg, lua-cmsgpack). If we pick luajit then finding the dependencies FAILS. - This commit groups detection of the lua interpreter with the lua dependencies it tries to find them for both the interpreters and choses the first one that has them. Helped-by: John Szakmeister <john@szakmeister.net>
2014-07-11 04:12:18 -07:00
unset(LUA_PRG_WORKS)
cmake: only set LUA_PRG with successful check (#11172) This is relevant for when using `USE_BUNDLED_LUAJIT=ON` with `USE_BUNDLED_LUAROCKS=OFF`, and then building without the necessary modules being installed/activated there yet: it would check the other (system) "lua" interpreters also, and in case all failed keep the `LUA_PRG` in the cache for the last failed entry - making it not re-check the previous ones on the next build (after you might have activated your custom LuaRocks installation). Only setting LUA_PRG if the check was successful handles the case better where it is configured already - we should not try to re-configure it then.
2019-10-07 08:42:40 -07:00
find_program(_CHECK_LUA_PRG ${CURRENT_LUA_PRG})
Check dependencies for each lua interpreter. - When USE_BUNDLED=OFF and the system has multiple lua interpreters (luajit AND lua) it may occur that only the later has the needed dependencies (lua-lpeg, lua-cmsgpack). If we pick luajit then finding the dependencies FAILS. - This commit groups detection of the lua interpreter with the lua dependencies it tries to find them for both the interpreters and choses the first one that has them. Helped-by: John Szakmeister <john@szakmeister.net>
2014-07-11 04:12:18 -07:00
cmake: only set LUA_PRG with successful check (#11172) This is relevant for when using `USE_BUNDLED_LUAJIT=ON` with `USE_BUNDLED_LUAROCKS=OFF`, and then building without the necessary modules being installed/activated there yet: it would check the other (system) "lua" interpreters also, and in case all failed keep the `LUA_PRG` in the cache for the last failed entry - making it not re-check the previous ones on the next build (after you might have activated your custom LuaRocks installation). Only setting LUA_PRG if the check was successful handles the case better where it is configured already - we should not try to re-configure it then.
2019-10-07 08:42:40 -07:00
if(_CHECK_LUA_PRG)
check_lua_deps(${_CHECK_LUA_PRG} "${LUA_DEPENDENCIES}" LUA_PRG_WORKS)
Check dependencies for each lua interpreter. - When USE_BUNDLED=OFF and the system has multiple lua interpreters (luajit AND lua) it may occur that only the later has the needed dependencies (lua-lpeg, lua-cmsgpack). If we pick luajit then finding the dependencies FAILS. - This commit groups detection of the lua interpreter with the lua dependencies it tries to find them for both the interpreters and choses the first one that has them. Helped-by: John Szakmeister <john@szakmeister.net>
2014-07-11 04:12:18 -07:00
if(LUA_PRG_WORKS)
cmake: only set LUA_PRG with successful check (#11172) This is relevant for when using `USE_BUNDLED_LUAJIT=ON` with `USE_BUNDLED_LUAROCKS=OFF`, and then building without the necessary modules being installed/activated there yet: it would check the other (system) "lua" interpreters also, and in case all failed keep the `LUA_PRG` in the cache for the last failed entry - making it not re-check the previous ones on the next build (after you might have activated your custom LuaRocks installation). Only setting LUA_PRG if the check was successful handles the case better where it is configured already - we should not try to re-configure it then.
2019-10-07 08:42:40 -07:00
set(LUA_PRG "${_CHECK_LUA_PRG}" CACHE FILEPATH "Path to a program.")
Check dependencies for each lua interpreter. - When USE_BUNDLED=OFF and the system has multiple lua interpreters (luajit AND lua) it may occur that only the later has the needed dependencies (lua-lpeg, lua-cmsgpack). If we pick luajit then finding the dependencies FAILS. - This commit groups detection of the lua interpreter with the lua dependencies it tries to find them for both the interpreters and choses the first one that has them. Helped-by: John Szakmeister <john@szakmeister.net>
2014-07-11 04:12:18 -07:00
break()
endif()
endif()
endforeach()
cmake: only set LUA_PRG with successful check (#11172) This is relevant for when using `USE_BUNDLED_LUAJIT=ON` with `USE_BUNDLED_LUAROCKS=OFF`, and then building without the necessary modules being installed/activated there yet: it would check the other (system) "lua" interpreters also, and in case all failed keep the `LUA_PRG` in the cache for the last failed entry - making it not re-check the previous ones on the next build (after you might have activated your custom LuaRocks installation). Only setting LUA_PRG if the check was successful handles the case better where it is configured already - we should not try to re-configure it then.
2019-10-07 08:42:40 -07:00
unset(_CHECK_LUA_PRG CACHE)
Check dependencies for each lua interpreter. - When USE_BUNDLED=OFF and the system has multiple lua interpreters (luajit AND lua) it may occur that only the later has the needed dependencies (lua-lpeg, lua-cmsgpack). If we pick luajit then finding the dependencies FAILS. - This commit groups detection of the lua interpreter with the lua dependencies it tries to find them for both the interpreters and choses the first one that has them. Helped-by: John Szakmeister <john@szakmeister.net>
2014-07-11 04:12:18 -07:00
else()
check_lua_deps(${LUA_PRG} "${LUA_DEPENDENCIES}" LUA_PRG_WORKS)
endif()
Add checks for lpeg/cmsgpack lua packages These checks will stop the build process with meaningful error messages if any of those packages are not installed.
2014-04-13 03:06:35 -07:00
Refactor the lua dependency checking. This is in preparation for the next step, which is to find a suitable lua interpreter, rather than just erroring when an interpreter is found but doesn't have the necessary dependencies. Helped-by: John Szakmeister <john@szakmeister.net>
2014-07-11 04:12:10 -07:00
if(NOT LUA_PRG_WORKS)
build: adjust some messages (#9087)
2018-10-06 09:45:34 -07:00
message(FATAL_ERROR "Failed to find a Lua 5.1-compatible interpreter")
Add checks for lpeg/cmsgpack lua packages These checks will stop the build process with meaningful error messages if any of those packages are not installed.
2014-04-13 03:06:35 -07:00
endif()
build: adjust some messages (#9087)
2018-10-06 09:45:34 -07:00
message(STATUS "Using Lua interpreter: ${LUA_PRG}")
Add checks for lpeg/cmsgpack lua packages These checks will stop the build process with meaningful error messages if any of those packages are not installed.
2014-04-13 03:06:35 -07:00
build: make generated source files reproducible #21586 Problem: Build is not reproducible, because generated source files (.c/.h/) are not deterministic, mostly because Lua pairs() is unordered by design (for security). https://github.com/LuaJIT/LuaJIT/issues/626#issuecomment-707005671 https://www.lua.org/manual/5.1/manual.html#pdf-next > The order in which the indices are enumerated is not specified [...] > >> The hardening of the VM deliberately randomizes string hashes. This in >> turn randomizes the iteration order of tables with string keys. Solution: - Update the code generation scripts to be deterministic. - That is only a partial solution: the exported function (funcs_metadata.generated.h) and ui event (ui_events_metadata.generated.h) metadata have some mpack'ed tables, which are not serialized deterministically. - As a workaround, introduce `PRG_GEN_LUA` cmake setting, so you can inject a modified build of luajit (with LUAJIT_SECURITY_PRN=0) that preserves table order. - Longer-term we should change the mpack'ed data structure so it no longer uses tables keyed by strings. Closes #20124 Co-Authored-By: dundargoc <gocdundar@gmail.com> Co-Authored-By: Arnout Engelen <arnout@bzzt.net>
2023-01-23 02:26:46 -07:00
# Some of the code generation still relies on stable table ordering in order to
# produce reproducible output - specifically the msgpack'ed data in
# funcs_metadata.generated.h and ui_events_metadata.generated.h. This should
# ideally be fixed in the generators, but until then as a workaround you may provide
# a specific lua implementation that provides the needed stability by setting LUA_GEN_PRG:
if(NOT LUA_GEN_PRG)
set(LUA_GEN_PRG "${LUA_PRG}" CACHE FILEPATH "Path to the lua used for code generation.")
endif()
message(STATUS "Using Lua interpreter for code generation: ${LUA_GEN_PRG}")
fix(build): don't disable byte precompilation on debug builds This special casing is redundant since long, as you can disable the binary cache regardless of build type with the --luamod-dev flag
2022-06-25 10:24:48 -07:00
option(COMPILE_LUA "Pre-compile Lua sources into bytecode (for sources that are included in the binary)" ON)
chore(build): add option to disable Lua bytecode compilation (#16722) Include a build option to explicitly disable Lua bytecode compilation. This is needed in some situations where the existing checks are not sufficient (e.g. cross compilation).
2021-12-19 14:00:53 -07:00
if(COMPILE_LUA AND NOT WIN32)
perf: pre-compile embedded Lua source into bytecode (#16631) The Lua modules that make up vim.lua are embedded as raw source files into the nvim binary. These sources are loaded by the Lua runtime on startuptime. We can pre-compile these sources into Lua bytecode before embedding them into the binary, which minimizes the size of the binary and improves startuptime.
2021-12-16 09:27:39 -07:00
if(PREFER_LUA)
foreach(CURRENT_LUAC_PRG luac5.1 luac)
find_program(_CHECK_LUAC_PRG ${CURRENT_LUAC_PRG})
if(_CHECK_LUAC_PRG)
set(LUAC_PRG "${_CHECK_LUAC_PRG} -s -o - %s" CACHE STRING "Format for compiling to Lua bytecode")
break()
endif()
endforeach()
elseif(LUA_PRG MATCHES "luajit")
fix(build): check that LuaJIT has required modules for compilation (#16714) Apparently some installations of LuaJIT do not have the "jit.bcsave" module which is required for pre-compilation. Check that this module exists before using LuaJIT as luac and if it doesn't, skip compiling bytecode.
2021-12-18 20:59:02 -07:00
check_lua_module(${LUA_PRG} "jit.bcsave" LUAJIT_HAS_JIT_BCSAVE)
if(LUAJIT_HAS_JIT_BCSAVE)
set(LUAC_PRG "${LUA_PRG} -b -s %s -" CACHE STRING "Format for compiling to Lua bytecode")
endif()
perf: pre-compile embedded Lua source into bytecode (#16631) The Lua modules that make up vim.lua are embedded as raw source files into the nvim binary. These sources are loaded by the Lua runtime on startuptime. We can pre-compile these sources into Lua bytecode before embedding them into the binary, which minimizes the size of the binary and improves startuptime.
2021-12-16 09:27:39 -07:00
endif()
endif()
if(LUAC_PRG)
message(STATUS "Using Lua compiler: ${LUAC_PRG}")
endif()
build(lint): fix luacheck not found #18940 Problem: Since 6d57bb89c1ee #18543, luacheck is not found on some systems when running the "lintlua" target. Solution: - Move the find_program() to the top-level CMakeLists.txt - Define a def_cmd_target() function with fewer assumptions than the old lint() function. - Move "lintuncrustify" to src/nvim/CMakeLists.txt so it can reuse the $LINT_NVIM_SOURCES already defined there. - Make the lint targets _fatal_ by default. There is little reason for the "lint" umbrella target defined in Makefile to exist if it's going to ignore the absence of the actual linters. - For now, keep the uncrustify call in a separate cmake script so that it can be silenced (too noisy).
2022-06-12 15:08:01 -07:00
#
# Lint
#
find_program(LUACHECK_PRG luacheck)
build: replace check-single-includes with clang-tidy (#22061) Clang-tidy already does what check-single-includes does automatically on top of its regular linting. It is also generator independent, so it doesn't take an eternity to run on slower generators such as Visual Studio.
2023-02-08 10:16:48 -07:00
find_program(SHELLCHECK_PRG shellcheck)
build(lint): fix luacheck not found #18940 Problem: Since 6d57bb89c1ee #18543, luacheck is not found on some systems when running the "lintlua" target. Solution: - Move the find_program() to the top-level CMakeLists.txt - Define a def_cmd_target() function with fewer assumptions than the old lint() function. - Move "lintuncrustify" to src/nvim/CMakeLists.txt so it can reuse the $LINT_NVIM_SOURCES already defined there. - Make the lint targets _fatal_ by default. There is little reason for the "lint" umbrella target defined in Makefile to exist if it's going to ignore the absence of the actual linters. - For now, keep the uncrustify call in a separate cmake script so that it can be silenced (too noisy).
2022-06-12 15:08:01 -07:00
find_program(STYLUA_PRG stylua)
find_program(UNCRUSTIFY_PRG uncrustify)
feat(build): add_glob_target runs only on changed files #19070 The general idea is that add_glob_targets creates a "touch file", a dummy file that acts as a dependency in order to check which files are outdated since the last time the target was run. Remove RunUncrustify.cmake as it's no longer necessary. It was initially introduced to silence its noisy output. The per-file targets will suppress the noisy output from uncrustify, except for the very first run. Also remove DefCmdTarget.cmake since add_glob_target already incorporates its functionality.
2022-06-30 05:10:05 -07:00
build: add EXCLUDE option to add_glob_target EXCLUDE filters out all elements containing regex, meaning it works on both files and directories. Also rename add_glob_targets to add_glob_target since only one target is being created.
2022-11-01 06:29:17 -07:00
add_glob_target(
feat(build): add_glob_target runs only on changed files #19070 The general idea is that add_glob_targets creates a "touch file", a dummy file that acts as a dependency in order to check which files are outdated since the last time the target was run. Remove RunUncrustify.cmake as it's no longer necessary. It was initially introduced to silence its noisy output. The per-file targets will suppress the noisy output from uncrustify, except for the very first run. Also remove DefCmdTarget.cmake since add_glob_target already incorporates its functionality.
2022-06-30 05:10:05 -07:00
REQUIRED
TARGET lintlua-luacheck
COMMAND ${LUACHECK_PRG}
FLAGS -q
GLOB_DIRS runtime/ scripts/ src/ test/
GLOB_PAT *.lua
build: remove clint error suppression #21782 Fix remaining clint errors and remove error suppression completely. Rename the lint targets to align with the established naming convention: - lintc-clint lints with clint.py. - lintc-uncrustify lints with uncrustify. - lintc runs both targets. lintc is also provided as a make target for convenience. After this change we can remove these files: https://github.com/neovim/doc/tree/gh-pages/reports/clint https://github.com/neovim/doc/blob/main/ci/clint-errors.sh
2023-01-13 16:48:10 -07:00
TOUCH_STRATEGY SINGLE)
feat(build): add_glob_target runs only on changed files #19070 The general idea is that add_glob_targets creates a "touch file", a dummy file that acts as a dependency in order to check which files are outdated since the last time the target was run. Remove RunUncrustify.cmake as it's no longer necessary. It was initially introduced to silence its noisy output. The per-file targets will suppress the noisy output from uncrustify, except for the very first run. Also remove DefCmdTarget.cmake since add_glob_target already incorporates its functionality.
2022-06-30 05:10:05 -07:00
build: add EXCLUDE option to add_glob_target EXCLUDE filters out all elements containing regex, meaning it works on both files and directories. Also rename add_glob_targets to add_glob_target since only one target is being created.
2022-11-01 06:29:17 -07:00
add_glob_target(
feat(build): add_glob_target runs only on changed files #19070 The general idea is that add_glob_targets creates a "touch file", a dummy file that acts as a dependency in order to check which files are outdated since the last time the target was run. Remove RunUncrustify.cmake as it's no longer necessary. It was initially introduced to silence its noisy output. The per-file targets will suppress the noisy output from uncrustify, except for the very first run. Also remove DefCmdTarget.cmake since add_glob_target already incorporates its functionality.
2022-06-30 05:10:05 -07:00
TARGET lintlua-stylua
COMMAND ${STYLUA_PRG}
FLAGS --color=always --check
GLOB_DIRS runtime/
GLOB_PAT *.lua
build: remove clint error suppression #21782 Fix remaining clint errors and remove error suppression completely. Rename the lint targets to align with the established naming convention: - lintc-clint lints with clint.py. - lintc-uncrustify lints with uncrustify. - lintc runs both targets. lintc is also provided as a make target for convenience. After this change we can remove these files: https://github.com/neovim/doc/tree/gh-pages/reports/clint https://github.com/neovim/doc/blob/main/ci/clint-errors.sh
2023-01-13 16:48:10 -07:00
TOUCH_STRATEGY SINGLE)
feat(build): add_glob_target runs only on changed files #19070 The general idea is that add_glob_targets creates a "touch file", a dummy file that acts as a dependency in order to check which files are outdated since the last time the target was run. Remove RunUncrustify.cmake as it's no longer necessary. It was initially introduced to silence its noisy output. The per-file targets will suppress the noisy output from uncrustify, except for the very first run. Also remove DefCmdTarget.cmake since add_glob_target already incorporates its functionality.
2022-06-30 05:10:05 -07:00
add_custom_target(lintlua)
add_dependencies(lintlua lintlua-luacheck lintlua-stylua)
build(lint): fix luacheck not found #18940 Problem: Since 6d57bb89c1ee #18543, luacheck is not found on some systems when running the "lintlua" target. Solution: - Move the find_program() to the top-level CMakeLists.txt - Define a def_cmd_target() function with fewer assumptions than the old lint() function. - Move "lintuncrustify" to src/nvim/CMakeLists.txt so it can reuse the $LINT_NVIM_SOURCES already defined there. - Make the lint targets _fatal_ by default. There is little reason for the "lint" umbrella target defined in Makefile to exist if it's going to ignore the absence of the actual linters. - For now, keep the uncrustify call in a separate cmake script so that it can be silenced (too noisy).
2022-06-12 15:08:01 -07:00
build: add EXCLUDE option to add_glob_target EXCLUDE filters out all elements containing regex, meaning it works on both files and directories. Also rename add_glob_targets to add_glob_target since only one target is being created.
2022-11-01 06:29:17 -07:00
add_glob_target(
feat(build): add_glob_target runs only on changed files #19070 The general idea is that add_glob_targets creates a "touch file", a dummy file that acts as a dependency in order to check which files are outdated since the last time the target was run. Remove RunUncrustify.cmake as it's no longer necessary. It was initially introduced to silence its noisy output. The per-file targets will suppress the noisy output from uncrustify, except for the very first run. Also remove DefCmdTarget.cmake since add_glob_target already incorporates its functionality.
2022-06-30 05:10:05 -07:00
TARGET lintsh
COMMAND ${SHELLCHECK_PRG}
build(lint): add more shell scripts to lintsh
2022-10-30 05:50:41 -07:00
FLAGS -x -a
GLOB_DIRS scripts ci
GLOB_PAT *.sh
EXCLUDE
scripts/pvscheck.sh
build: remove clint error suppression #21782 Fix remaining clint errors and remove error suppression completely. Rename the lint targets to align with the established naming convention: - lintc-clint lints with clint.py. - lintc-uncrustify lints with uncrustify. - lintc runs both targets. lintc is also provided as a make target for convenience. After this change we can remove these files: https://github.com/neovim/doc/tree/gh-pages/reports/clint https://github.com/neovim/doc/blob/main/ci/clint-errors.sh
2023-01-13 16:48:10 -07:00
TOUCH_STRATEGY SINGLE)
build: install with the correct permissions The install() command will create the parent directories, but it does so with the user's umask. We want to do our best to make sure the correct permissions are being set, without clobbering existing permissions. To do this, this commit introduces an install_helper(), which is similar in signature to the install() command, to help ensure that directories are created ahead of the actual install() command. This will attempt to use 0644 permissions for files and 0755 permissions for directories by default--though they can be overridden. To make this work correctly, without trying to introduce some mechanism with setting the umask, it meant that there's a small portion that makes use of an "internal" version of the file() command. It has been tested on CMake 2.8.11, 2.8.12, and 3.0.2, and works correctly on all versions. This fixes #1201 and #1086.
2014-09-19 04:37:22 -07:00
build: move lint target to cmake #19169 This will ensure less verbose output and faster linting.
2022-07-01 09:15:04 -07:00
add_custom_target(lintcommit
COMMAND ${PROJECT_BINARY_DIR}/bin/nvim -u NONE -es -c [[lua require('scripts.lintcommit').main({trace=false})]]
WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}
VERBATIM)
add_dependencies(lintcommit nvim)
add_custom_target(lint)
build: replace check-single-includes with clang-tidy (#22061) Clang-tidy already does what check-single-includes does automatically on top of its regular linting. It is also generator independent, so it doesn't take an eternity to run on slower generators such as Visual Studio.
2023-02-08 10:16:48 -07:00
add_dependencies(lint clang-tidy lintc lintlua lintsh lintcommit)
build: move lint target to cmake #19169 This will ensure less verbose output and faster linting.
2022-07-01 09:15:04 -07:00
build: add formatting targets for c and lua files (#19488) The targets will only format files that have been changed in current branch compared to the master branch. This includes unstaged, staged and committed files. Add following make and cmake targets: formatc - format changed c files formatlua - format changed lua files format - run formatc and formatlua Remove scripts/uncrustify.sh as this deprecates it.
2022-08-02 03:32:57 -07:00
#
# Format
#
add_custom_target(formatlua
COMMAND ${CMAKE_COMMAND}
-D FORMAT_PRG=${STYLUA_PRG}
-D LANG=lua
-P ${PROJECT_SOURCE_DIR}/cmake/Format.cmake
WORKING_DIRECTORY ${PROJECT_SOURCE_DIR})
add_custom_target(format)
add_dependencies(format formatc formatlua)
Build: Use GNUInstallDirs, install man pages #2649 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>
2015-05-17 11:45:30 -07:00
install_helper(
build: move man/ to src/man/ #19119 Problem: man/ contains source files for manpage generation, it doesn't need to live at the project root. Solution: Move it to src/man/.
2022-06-27 01:02:02 -07:00
FILES ${CMAKE_SOURCE_DIR}/src/man/nvim.1
Build: Use GNUInstallDirs, install man pages #2649 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>
2015-05-17 11:45:30 -07:00
DESTINATION ${CMAKE_INSTALL_MANDIR}/man1)
build(Windows): make bundling nvim-qt optional (#21866) Closes https://github.com/neovim/neovim/issues/14552.
2023-02-08 02:08:18 -07:00
if(EXISTS "${DEPS_PREFIX}/share/nvim-qt")
option(USE_BUNDLED_NVIMQT "Bundle neovim-qt" ON)
else()
option(USE_BUNDLED_NVIMQT "Bundle neovim-qt" OFF)
endif()
build: install with the correct permissions The install() command will create the parent directories, but it does so with the user's umask. We want to do our best to make sure the correct permissions are being set, without clobbering existing permissions. To do this, this commit introduces an install_helper(), which is similar in signature to the install() command, to help ensure that directories are created ahead of the actual install() command. This will attempt to use 0644 permissions for files and 0755 permissions for directories by default--though they can be overridden. To make this work correctly, without trying to introduce some mechanism with setting the umask, it meant that there's a small portion that makes use of an "internal" version of the file() command. It has been tested on CMake 2.8.11, 2.8.12, and 3.0.2, and works correctly on all versions. This fixes #1201 and #1086.
2014-09-19 04:37:22 -07:00
add_subdirectory(src/nvim)
build: rename build-related dirs 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/)
2022-06-27 03:08:59 -07:00
add_subdirectory(cmake.config)
cmake: Generate tags and some vim syntax elements
2015-04-02 09:45:34 -07:00
add_subdirectory(runtime)
build: create test/CMakeLists.txt and move test-related code (#22179) Having a clear separation between build code and test code makes it easier to get a higher-level understanding of how the neovim build works.
2023-02-08 15:46:39 -07:00
add_subdirectory(test)
build(Windows): make bundling nvim-qt optional (#21866) Closes https://github.com/neovim/neovim/issues/14552.
2023-02-08 02:08:18 -07:00
if(WIN32 AND USE_BUNDLED_NVIMQT)
win/package: move gui shim to its runtime folder (#8418) Close #7517 gui shim is for nvim-qt only.
2018-05-19 23:27:52 -07:00
install_helper(
FILES ${DEPS_PREFIX}/share/nvim-qt/runtime/plugin/nvim_gui_shim.vim
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/nvim-qt/runtime/plugin)
endif()
job: Allow spawning jobs connected to pseudo terminals
2015-02-23 08:34:20 -07:00
build(cmake): simplify and speed up the uninstall target 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.
2022-06-17 05:11:08 -07:00
add_custom_target(uninstall
COMMAND ${CMAKE_COMMAND} -P ${PROJECT_SOURCE_DIR}/cmake/UninstallHelper.cmake)
ci: improved cpack packaging Addresses: #12571 - Added the following installers through CMake files: - Windows NSIS. - Windows MSI. - Windows zip. - MacOs tarball. - Linux tarball. - Linux Deb package. - Tweaked pipeline CPack commands to build using new CMakeLists.txt configuration file. - Added icons and relevant packaging files. - Updated notes.md to reflect new installation instructions. This isn't meant to be the perfect solution, it's simply a first pass at using a simple packaging system to build Windows installers. A Debian package has also been added since it's very easy but other packages have been left out due to limiting the scope. Hopefully we can build further upon this and improve it over time with code signing, better icons and more user-friendly installation graphics and so on.
2022-02-07 13:49:09 -07:00
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
build: rename build-related dirs 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/)
2022-06-27 03:08:59 -07:00
add_subdirectory(cmake.packaging)
ci: improved cpack packaging Addresses: #12571 - Added the following installers through CMake files: - Windows NSIS. - Windows MSI. - Windows zip. - MacOs tarball. - Linux tarball. - Linux Deb package. - Tweaked pipeline CPack commands to build using new CMakeLists.txt configuration file. - Added icons and relevant packaging files. - Updated notes.md to reflect new installation instructions. This isn't meant to be the perfect solution, it's simply a first pass at using a simple packaging system to build Windows installers. A Debian package has also been added since it's very easy but other packages have been left out due to limiting the scope. Hopefully we can build further upon this and improve it over time with code signing, better icons and more user-friendly installation graphics and so on.
2022-02-07 13:49:09 -07:00
endif()
Reference in New Issue Copy Permalink