* Remove C++ requirement if test is disabled
* Change CMake package name of C library to msgpack-c
* Unified all C package, library, cmake, tarball name become msgpack-c.
- 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 09118052ce.
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.
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.
By default, find_library() searches all directories for one possible
name and then looks for the next name. To make sure we're building
against the same headers and libraries, look for all names in a
directory before moving to the next one.
In 33bc332, version constraints were added to pkg_search_module(), but
that only affects the set of directories searched by
find_library()/find_path().
Once the header directory is found, parse the version from
version_master.h so it can be checked by the find_package() call in the
root CMakeLists.txt.
libmsgpack was the old C++ library provided by msgpack-c. The C library
is libmsgpackc.
The C++ support became header-only, but there was a bug
(msgpack/msgpack-c#395) wherein using msgpack-c's CMake build system
would only install libmsgpack instead of libmsgpackc.
Searching for both libraries, but preferring libmsgpackc, allows for
building against older msgpack-c releases and prepares for the upcoming
msgpack-c release which fixes the aforementioned issues.
Signed-off-by: James McCoy <jamessan@jamessan.com>
Using msgpack v5 will let nvim be more compatible with msgpack libraries for
other platforms.
This also replaces "raw" references by "bin" which is the new name for msgpack
binary data type
