Skip to content

Conversation

rjw57
Copy link
Contributor

@rjw57 rjw57 commented Feb 24, 2014

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 standard CMAKE_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.

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.
rjw57 referenced this pull request in fhahn/neovim Feb 24, 2014
@rjw57
Copy link
Contributor Author

rjw57 commented Feb 24, 2014

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.
@rjw57
Copy link
Contributor Author

rjw57 commented Feb 25, 2014

In d1a79dc we should probably add a LibUV_USE_STATIC_LIBS variable to configure the behaviour but the FindLibUV.cmake module should just do what we want it to do without adding complexity. If anyone's CMake bone is throbbing it is an easy fix.

@ashleyh
Copy link
Contributor

ashleyh commented Feb 25, 2014

This looks good, but given the controversy over system vs. bundled libuv perhaps the cmake target in the Makefile shouldn't depend on deps? Presumably if you make cmake without make deps it would pick up the system libuv?

@rjw57
Copy link
Contributor Author

rjw57 commented Feb 25, 2014

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 make deps separate anyway so that it could be a before_script in Travis.

@rjw57 rjw57 mentioned this pull request Feb 25, 2014
@rjw57
Copy link
Contributor Author

rjw57 commented Feb 25, 2014

Merged latest master.

@tarruda
Copy link
Member

tarruda commented Feb 26, 2014

@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?

@rjw57
Copy link
Contributor Author

rjw57 commented Feb 26, 2014

Yup. Funnily enough I was just working on this :).

@rjw57
Copy link
Contributor Author

rjw57 commented Feb 26, 2014

@tarruda You're right. Although strangely the branch compiles on my machine here without problems. I'll put in a speculative fix based on #128.

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.
@rjw57
Copy link
Contributor Author

rjw57 commented Feb 26, 2014

I've pushed a possible fix. If it builds and @tarruda wants to merge I'll rebase onto current master.

@tarruda
Copy link
Member

tarruda commented Feb 26, 2014

No need, thanks

dwb pushed a commit to dwb/neovim that referenced this pull request Feb 21, 2017
butwerenotthereyet pushed a commit to butwerenotthereyet/neovim that referenced this pull request Dec 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants