-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
Make libuv handling more idiomatic for CMake #116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The CMake prefix path is the set of directories CMake searches for libraries, header files, etc. Use the .deps directory we create when building libuv as one of those locations.
Idiomatically discover if libuv is installed.
CMake now required libuv so fetch it first.
We use the standard CMAKE_PREFIX_PATH variable to pass the location of .deps as a search location on the command line. There is now no need for explicitly hard-coding it.
Conflicts: src/CMakeLists.txt
Updated to handle vim executable rename to nvim from 9db0fc3. |
Explicitly try to find the static libuv library first. This might be considered a hack and if it weren't a single-use module it might be preferable to control static versus shared preferences with a configuration variable.
In d1a79dc we should probably add a |
This looks good, but given the controversy over system vs. bundled libuv perhaps the |
Yup. Although in that case you might as well run CMake directly which is what any packaging script in a distro would do. Using CMake directly picks up on the system libuv. It would make a degree of sense to have |
Conflicts: Makefile
Merged latest master. |
@rjw57 You've made good points, but the PR is failing because its missing 'rt' symbols, perhaps the cmake find module needs extra configuration for static links? |
Yup. Funnily enough I was just working on this :). |
As noted in neovim#128, if clock_gettime is provided by librt then it does not end up being linked into the static libuv.a binary. This might be considered a bug in libuv but we can address it here. Detect if librt provides the clock_gettime symbol and, if so, append it to the list of libraries linked into nvim. On non-librt systems the behaviour should be as before.
I've pushed a possible fix. If it builds and @tarruda wants to merge I'll rebase onto current master. |
No need, thanks |
The build for #3 is failing at the moment but this addresses a similar issue. Instead of a) not checking for libuv and b) hard-coding the
.deps
directory, use a more idiomatic way of handling libuv. As noted in the description for #99 it is more usual for one to write a custom CMake module to find any compile-time dependencies. This PR adds such a mechanism for libuv and also uses the standardCMAKE_PREFIX_PATH
variable to tell CMake where to find the non-system libraries we install.This allows compilation with the system libuv (if any) when using the standard CMake
mkdir build && cd build && cmake .. && make
workflow. The practical upshot of this being that packaging neovim for, e.g., Debian using a system-supplied libuv is trivial: neovim will behave like a completely standard CMake-based bit of software.Since CMake now checks for the presence of libuv, move the fetching and compiling of it to the
make cmake
target.