Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cquery fails to compile due to poor decisions about finding libclang and ncurses libraries #483
I would like to use cquery, but I cannot even compile it due to poor decisions it makes about locating libclang (and ncurses).
When I try to build cquery:
OK. So I look at config.log and see this at the end:
This is extremely broken, in at least two different ways. I'm on Fedora 27. First, I already have libclang a working copy of libclang 5.0.1 installed:
So why is cquery trying to use a vendored copy of libclang? I already have a perfectly fine copy installed, and it's just as recent as the bundled version.
The second issue is that you cannot reasonably expect to ship dynamic libraries this way. First I see what the vendored libclang links against:
Huh? Why is there a warning from ldd? Well, apparently the
Whatever, that's not really the issue. The issue is that Ubuntu 14 uses
What I would like to see:
Related to Fedora #474
To use a system clang, https://github.com/cquery-project/cquery/wiki/Build#system-clang---llvm-configllvm-config
Each platform may have different llvm-config paths (some may have suffixes, some are located in unconventional paths (Nix), Windows does not have llvm-config.exe)
The system libclang.so.5.0.1 SIGSEGV when indexing default arguments of template template parameters. The default
libclang cannot be built locally easily, because you would need to download clang+llvm and build thousands of .cpp files. It may likely take more than 3 hours to build on a laptop.
We'd be happy to take a look at a PR.
Certain versions of clang do not work well. Using vendored deps is the most reliable solution for the vast majority of users.
Takes too long, as @MaskRay said.
The ideal long-term solution is to ship a prebuilt cquery (so you just install the extension in your client of choice and you're done).
If the ideal solution means catering to only the "vast majority of users" you should also understand that you're alienating users who understand and care about how such software is built. If you want to ship pre-built binaries to the vast majority of users that's fine. But that's not what I asked for: I want to build software the right way.
This is just my personal opinion: Shipping pre-built binaries is antithetical to the open source tradition, and is inherently non-portable. FWIW, rtags is able to detect my system libclang and link against it just fine. I'm familiar enough with autotools and pkg-config but I don't know enough about waf to help with a PR. If you're able to figure this out at some point in the future I'll try cquery again.
If you consider
Yes, waf is alien enough, but it is also supported by FreeBSD ports https://github.com/HenryHu/ports/blob/master/devel/cquery/Makefile
You like the numerous
@eklitzke Sorry for my inconsiderate words "I have to say bye." But I would not be active for this project. If you want to read the long story you may join https://gitter.im/cquery-project/Lobby
@DaanDeMeyer has contributed a cmake build system and I hope that might make you feel friendlier.
There are quite a few goodies in https://github.com/cquery-project/emacs-cquery that might attract you. Take a look at https://github.com/cquery-project/cquery/wiki/Emacs , consider contributing these features to rtags or take over emacs-cquery.