| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
CMake can handle building universal binaries on macOS using the
`CMAKE_OSX_ARCHITECTURES` variable. Let's pass this variable to the
relevant dep builds. We use the `LIST_SEPARATOR` argument to prevent the
shell from interpreting the `;` that CMake uses as a list separator.
For dependencies that don't build using CMake, we only need to make sure
that the compiler is invoked with the correct `-arch` flags. The
compiler does the rest.
The only exception to this is the LuaJIT build, which we handle
separately as a special case.
|
| |
|
|
| |
This is rarely, if ever, used and certainly not tested. It's likely this
isn't functional anymore.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unnecessary CI builds increase the change of spurious failures, which are costly
noise. Of course, we should fix all legitimate bugs, but we also cannot
micro-manage every platform, so there needs to be a clear motivation for the CI
builds that we maintain.
Reasons against maintaining a mingw CI job:
1. The windows mingw build is slow.
2. Failures:
- https://github.com/neovim/neovim/issues/18494
- https://github.com/neovim/neovim/issues/18495
3. The mingw artifact is 10x bigger than the windows MSVC artifact:
https://github.com/neovim/neovim/issues/10560
4. Our releases publish the MSVC (not mingw) artifact for Windows users:
https://github.com/neovim/neovim/releases
5. Non-MSVCRT has limitations documented by libuv: http://docs.libuv.org/en/v1.x/process.html
> On Windows file descriptors greater than 2 are available to the child process only if the child processes uses the MSVCRT runtime.
Closes https://github.com/neovim/neovim/issues/18551
|
| |
|
|
| |
see https://github.com/msgpack/msgpack-c/releases/tag/c-4.0.0
|
| |
|
|
|
|
|
|
| |
The VS 2019 CMake generator no longer has different generator types for
different architectures. Now, the architecture is specified via CMake's
`-A` switch. However, this requires we also propagate
`${CMAKE_GENERATOR_PLATFORM}` to the bundled deps, so they build for the
same architecture as Nvim.
|
| |
|
|
|
|
| |
* 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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Added recipes to build bundled dependencies in native MinGW
toolchains - libuv, luajit, luarocks, msgpack
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using /MT was causing issues when building luarocks, revert it, use the
dynammic runtime and generate release DLLs for the dependencies.
Some refactoring was required because for linking cmake looks for the
import libraries (.lib) but on runtime executables we need the .dll files
to be in the same folder.
The DLLs are placed in the bin/ folder in order for nvim.exe to run
during the build and tests. The install target installs the DLLs with
the nvim binary - uses GetPrerequisites to find runtime DLLs.
Some minor issues that required adjustments:
- [MSVC] FindMsgpack.cmake now looks for msgpack_import.lib instead of
msgpack.lib
- The lua-client fails to find libuv.lib, instead it looks for uv.lib,
added second copy of the file to the install command.
- [MSVC] CMAKE_BUILD_TYPE affects the output paths, default to Release.
Part of these changes are credited to @jasonwilliams200OK who fixed the
third-party recipes to consistently use the same build type.
|
| |
|
|
|
|
|
|
|
|
| |
Although UNIX is a registered trademark of The Open Group, it doesn't
really matter whether we refer to these systems as UNIX, Unix, or
Unix-like. So, for consistency, refer to them collectively as Unix.
Related:
http://www.greens.org/about/unix.html
http://www.unixica.com/html/unixunix.html
|
| |
|
|
|
|
|
|
| |
Introduce ALLOW_EXISTING_SRC_DIR option, turned off by default.
The Homebrew formula, which downloads and extracts the third-party
dependency sources before starting the build, would turn this option
ON.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Update recipes to build with MSVC or cross compile in Unix with Mingw
- For recipes that need to be reused, wrap recipe in CMake function
using cmake_parse_arguments
- New directory .deps/host is the install root for HOST targets, the old
.deps/usr is used for TARGET
- In windows disable builds for terminal libraries and jemalloc
- Added cmake script CopyFilesGlob.cmake to copy files using glob
cmake -DFROM_GLOB=*.h -DTO=/usr/include -P CopyFilesGlob.cmake
- New CMake variables HOSTDEPS_* can be used in cross compile recipes.
Except when the target is UNIX, since that would break 32bit builds
in 64bit Unix systems using the Travis 32bit toolchain
|
| | |
|
| |
|
