Package Details: vim-youcompleteme-git r3216.0d855962-1

Git Clone URL: https://aur.archlinux.org/vim-youcompleteme-git.git (read-only, click to copy)
Package Base: vim-youcompleteme-git
Description: A code-completion engine for Vim
Upstream URL: https://ycm-core.github.io/YouCompleteMe/
Keywords: completion engine neovim vim ycm
Licenses: GPL3
Groups: vim-plugins
Submitter: thestinger
Maintainer: artafinde
Last Packager: artafinde
Votes: 170
Popularity: 0.50
First Submitted: 2013-02-05 21:32 (UTC)
Last Updated: 2024-08-19 15:53 (UTC)

Dependencies (19)

Required by (0)

Sources (2)

Pinned Comments

artafinde commented on 2021-04-10 13:03 (UTC)

If you want to use system's abseil set the _use_system_abseil to ON - default is to download from internet during build.

Latest Comments

« First ‹ Previous 1 .. 37 38 39 40 41 42 43 44 45 46 47 .. 53 Next › Last »

eberan commented on 2015-04-22 02:31 (UTC)

@marsoft Yeah it looks like your environment is a little screwy, with libclang being selected from your Android SDK path. I suppose this wouldn't happen if we went with the non-system clang library. I'd say the slightly more proper way of building in your case is to set LIBRARY_PATH (and maybe PATH?) to /usr/lib, as that is where your system libs live. #LIBRARY_PATH=/usr/lib makepkg That said, I would recommend you clean your $path up a little, as it could make other programs

marsoft commented on 2015-04-21 19:52 (UTC)

Had an issue, when after building I got error message like this: [ 85%] Built target ycm_client_support Linking CXX shared library /tmp/packerbuild-1000/vim-youcompleteme-git/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/ycm_core.so /opt/android-sdk/build-tools/19.0.3/libclang.so: error adding symbols: Incorrect file format What helped was to export PATH=/usr/bin and clean rebuild: $ export PATH=/usr/bin $ makepkg -C The strange thing is that android SDK paths were in PATH but *after* /usr/bin, so in theory it should not influence anything... My PATH is: /home/mars/bin:/home/mars/GNUstep/Tools:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/android-sdk/build-tools/19.0.3/:/opt/android-sdk/platform-tools:/opt/android-sdk/tools:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/mars/.gem/ruby/2.1.0/bin:/opt/arm-cs-tools/bin Anyway, hope this will help.

eberan commented on 2015-04-14 22:02 (UTC)

@SevenHong Don't build packages as root. Take a look at the makepkg wiki entry; "makepkg does not support building as root as of v4.2."

<deleted-account> commented on 2015-04-13 03:00 (UTC)

I was using packer and I got this error: makepkg: invalid option '--asroot' The build failed. Any help?

eberan commented on 2015-03-26 18:47 (UTC)

@yan12125 Well it sounds like rpath isn't being used (when using system lib) and wont be fixed or at least there is no plan to. Considering we've been using the system lib forever anyway, with no reported ill effects outside of needing a rebuild, we can explicitly not package it without changing behavior.

yan12125 commented on 2015-03-25 18:08 (UTC)

Valloric responded again. Any further ideas? By the way, I prefer the latter solution by @eberan, too.

swiftscythe commented on 2015-03-23 17:52 (UTC)

@eberan, I am more inclined to the latter. I've been using YCM for more than a year and the developer has always updated the plugin for API/ABI changes in libclang almost as soon as they are released, which is before it even hits the arch repos.

eberan commented on 2015-03-23 17:47 (UTC)

@yan12125 Valloric responded: "...@rpath and other wonkiness is there to ensure that that libclang is loaded." Interesting, I never used rpath before! Thanks for posting to github though, that helps in deciding what to do with packaging; Essentially we need to pull in the libclang dependencies as well. Alternatively we could just use system libraries and hope the ABI etc don't break on system upgrades. The former bloats the plugin just a little, the latter breaks if the system library is incompatible with the API/ABI of ycm_core.so *and* might not be fixable until upstream updates their code to the latest clang/llvm (i.e. just rebuilding the plugin may not help). Opinions are welcome, but I'm leaning towards the former; include dependencies in the package.

« First ‹ Previous 1 .. 37 38 39 40 41 42 43 44 45 46 47 .. 53 Next › Last »