| 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/)
|
| |
|
|
|
|
|
|
| |
Problem: #19029 added a new fallback that sets
`$MACOSX_DEPLOYMENT_TARGET` to the local macOS version via `sw_vers`.
However, the output included a newline, which broke the generated Ninja
build script.
Solution: use `OUTPUT_STRIP_TRAILING_WHITESPACE` for `execute_process`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To build universal binaries on macOS, one typically only needs to pass
multiple `-arch` flags to `clang`.
Unfortunately, this strategy causes LuaJIT builds to fail. To work
around this, we build LuaJIT for each requested architecture
individually first and then use `lipo` to package each architecture
slice into a universal binary.
To be able to do this on an Intel macOS host or an M1 macOS host without
a Rosetta installation, we need some special flags in order to tell
LuaJIT that it is cross-compiling for a different target. See [1] for
details.
[1] https://luajit.org/install.html#cross
|
| |
|
|
| |
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
|
| | |
|
| |
|
|
| |
fixup for #16041 (`amalg` build is recommended by LuaJIT for performance
but this way of doing it breaks parallel build with `make -j`)
|
| |
|
|
|
| |
bump LuaJIT to https://github.com/LuaJIT/LuaJIT/commit/b4b2dce9fc3ffaaaede39b36d06415311e2aa516
now requires `-funwind-tables` build flag, which conflicts with
`-DLUA_USE_ASSERT`
|
| |
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
| |
LuaJIT build now requires specifying a deployment target, so use the
same baseline as our nightly builds.
Co-authored-by: Christian Clason <christian.clason@uni-due.de>
|
| |
|
|
|
|
| |
Fixes LuaJIT build on macOS Catalina.
ref https://github.com/LuaJIT/LuaJIT/issues/521
ref https://github.com/Homebrew/homebrew-core/pull/46823
|
| | |
|
| |
|
|
|
|
|
|
| |
This was added in 4c92a0bac to help with debugging, but could also have been
just moved there instead of disabling it manually (which was done due to
issues on Travis with OSX).
Since the JIT is the main feature of luajit, we should not disable it,
especially not during compile time.
|
| |
|
|
|
| |
prevent luajit to assigning default value to MACOSX_DEPLOYMENT_TARGET
ref #9050
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Libuv and LuaJIT like to hide the actual compilation and linking
commands behind nice text. This change makes them spit out the actual
command line to help us with debugging issues that people are seeing.
|
| |
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
