Currently, the release build picks up headers in
`/Library/Frameworks/Mono.framework/Headers`. You can verify this by
downloading the latest nightly build and checking the output of `nvim
--version`.
These headers are likely to be from a different version of `libintl` than the
one we link to. Let's avoid usage of them by setting `CMAKE_FIND_FRAMEWORK` to
`NEVER`.
Installing the ruby provider takes anything between 1 and 1.5 minutes on
Windows, which is a big drain on our CI. Remove it until we find a more
sustainable solution.
The lua client is no longer needed after
d6279f9392. One of its dependencies,
mpack, is still needed however. Remove lua-nvim and replace it with
lua-mpack.
The other packages are most likely not needed as we no longer run tests
for external dependencies.
If one uses .deps when DEPS_BUILD_DIR is defined in another location it
leads to very surprising behaviors, as it looks for libraries in other
places other than .deps.
Currently files to install in runtime/ is detected by recursive glob
pattern which has two problems:
- cmake needs to do a of work at config time and
build/runtime/cmake_install.cmake becomes HUGE (2.5MB, biggest config file)
- we need to explicitly specify each file suffix used in the entire
runtime, which is duplication of information.
These globs specify every single file in a subdirectory.
Thus, we can just install every runtime/ subdirectory as a single
install command. Furthermore, at the top-level, only .vim and .lua files
need to be installed.
Further possible refactor: we could move files which does not belong
in $PREFIX/runtime out of $REPO/runtime. Then runtime could be installed
with a single install_helper(DIRECTORY ...) command.
Having separate directory location causes failures to be inconsistent
and ultimately confusing. A common problem is a file with a particular
name is searched for the entire repository, which gives different
results if the dependency directory is inside the neovim directory or
outside of it.
Having to specify CI_BUILD for every CI job requires boilerplate. More
importantly, it's easy to forget to enable CI_BUILD, as seen by
8a20f9f98a. It's simpler to remember to
turn CI_BUILD off when a job errors instead of remembering that every
new job should have CI_BUILD on.
Multi-config generators can be tricky so testing them would be good.
Also test GCC release and MinSizeRel build types as they're prone to
unusual warnings. Remove release testing from test.yml as this is a
sufficient replacement.
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.
