| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
- Remove unused code
- Use consistent casing. Variable names such as LibLuV_LIBRARIES is
needlessly jarring, even if the name might be technically correct.
- Use title casing for packages. find_package(unibilium) requires the
find_module to be named "Findunibilium.cmake", which makes it harder
to spot when scanning the files. Instead, use "Unibilium".
|
| |
|
|
|
|
| |
Large parts the library weren't being used, and the parts that were was overly
abstracted for our use case. Additionally, part of its use case was to abstract
pkgconfig boilerplate, which is no longer needed as pkgconfig has been removed
in favor of relying on cmake alone in 09118052cee5aef978d6075db5287c1b6c27381a.
|
| |
|
| |
Cmake should already be able to find everything on its own.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This was discouraged (as an option) in 5b5d353151 [1], not enabled/used by
default, and not working according to the comment in local.mk.example.
Taken out of https://github.com/neovim/neovim/pull/10395.
1: https://github.com/neovim/neovim/pull/2465
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The variables are not meant to be defined there really, but only with
the third-party project.
Using them, e.g. with the following, would actually result in libvterm
not being found then:
make CMAKE_EXTRA_FLAGS="-DUSE_BUNDLED_LIBVTERM=ON" \
DEPS_CMAKE_FLAGS="-DUSE_BUNDLED=OFF -DUSE_BUNDLED_LIBVTERM=ON"
In https://github.com/neovim/neovim/pull/6357 they were renamed to
`USE_BUNDLED_X` from `X_USE_BUNDLED`, but the above reasoning applies
to the old names, too.
Internally `CMAKE_PREFIX_PATH` is used to add the built/bundled third
party packages for `find_package`, so there is no reason to e.g. query
the values via `load_cache` for example from the third-party project.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
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.
|
