This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
Link the already-packaged typescript package so that ycmd will support
completions for javascript and typescript filetypes.
The structure of these installation directories is "documented" here:
<https://github.com/ycm-core/ycmd/blob/master/build.py>.
I don't completely understand why the language support is passed as
optional attrs Is it because folks want to build leaner packages and
pass null or because they want to target particular dependencies? At any
rate I followed the pattern.
ycmd gives 'no completer support' because of missing 'gopls'.
Add this as a conditional dependency.
Refactor the 'mkdir -p' step to be conditional per-dependency,
and placed just before the link step.
This is mostly for legibility but also pedantic correctness:
do not create a directory unless it will be used.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
Copy _all_ of 'third_party'.
Cherry-picking the contents of this dir is a fragile approach as
they change in later commits (breaking this build).
This approach continues to work on the current build,
and will not break with later versions of the project.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
Now works with newer version of vim youcompleteme plugin.
Details:
- The OS X patch is no longer necessary as that code was removed upstream.
- It seems to want LLVM version 4 now.
- It annoyingly wants to symlink libclang.4 to libclang.4.0; nix already
did this.
YouCompleteMe needs the packages to be available in ycmd's third_party
directory, and things start getting pretty complicated when we try to
use our package libs instead of the vendored ones. We can revisit this
at a later time, but we'll need to ensure that we don't break the vim
plugin.
Tested in vim.
This also fixes build for Mac OS X. The build failed before because both
clang and clang-unwrapped were in scope and CMake tried to compile the
library with unwrapped clang with well-understood consequences.
This commit fixes the issue by passing libclang through a different way.