Closed jaelsasser closed 6 years ago
You can use cquery-project-roots
, rather than change the logic.
Locating compile_commands.json
is bad for projects with generated files in the build directory.
If you have other concerns, chime in in https://github.com/emacs-lsp/lsp-mode/issues/293
Looking through the discussion now.
My main annoyance with this is that it breaks pretty much every project I use with lsp-mode
with. I burned about half an hour regenerating compile_commands.json
files and bisecting cquery
itself to try and find the issue, only to realize that the project root detection had changed drastically overnight.
Also, the existing logic is a violation of the compile_commands.json spec:
Clang tools are pointed to the top of the build directory to detect the file and use the compilation database to parse C++ code in the source tree.
Having a symlink in the project root compile_commands.json
pointing to build/compile_commands.json
is easy for clients. You PR will make generated files hard
.cquery
can be hierarchical and locate-dominating-file
will incorrectly take the subdirectories as :rootUri of files in subdirectories. locate-dominating-file
is a convenience tool for non-trivial projects but it gets in the way for larger projects. Your PR is not moving in the right direction.
I can't symlink in my project root, I have about eight or nine different subprojects in my work monorepo. This change broke all of them.
@MaskRay how about I revise the patch to centre around a defcustom
list option to determine the order of the built-in root file detectors? I'm reading through the documentation for the allowed :type
params and I should be able to set something up that makes it easy for users to:
string
to be passed to locate-dominating-file
directory
to be matched using cquery-project-roots
cquery-get-root-projectile
provided by default)".cquery"
from the default list definition to never match on a .cquery
definition)A customizable project root detection list will be helpful, but IMO it re-invents logic of projectile
(defcustom projectile-project-root-files-functions
'(projectile-root-local
projectile-root-bottom-up
projectile-root-top-down
projectile-root-top-down-recurring)
"A list of functions for finding project roots."
:group 'projectile
:type '(repeat function))
Your scheme will be definitely better than the current makeshift but it would also complicate things.
I raised emacs-lsp/lsp-mode#293 because I hope other language client/server users discuss this as it is a general problem.
When the general solution surfaces, the cquery project detection logic will become unnecessary.
cquery-project-root-function
cquery-project-roots
shall be much simpler approaches for your case.
My issue is that I never projectile
to have anything whatsoever to do with setting up an LSP buffer. My goal is to get a way to disable it (or at least lower its priority preference) without needing a defadvice
hack.
On master
right now, I need to explicitly blacklist / whitelist to work around the fact that lsp-cquery
thinks that it can start in every C/C++ source directory that happens to be checked into a git repo. I got the following on my local checkout of WireGuard, which doesn't have a compile_commands.json
file:
LIBCLANG TOOLING ERROR: json-compilation-database: Error while opening JSON database: No such file or directory
2018-03-03 12:04:50.773 ( 0.001s) [querydb ] project.cc:310 WARN| cquery has no clang arguments. Considering adding either a compile_commands.json or .cquery file. See the cquery README for more information.
If you call lsp-cquery-enable in c-mode-common-hook
, you may customize lsp-project-blacklist
(use-package cquery
:commands lsp-cquery-enable
:init (add-hook 'c-mode-common-hook #'cquery//enable)
;; .........
))
@MaskRay how's the revised patch look? I think this strikes a compromise between our different setups -- it allows setups with layered projects where the only compile_commands.json
that matters is the topmost one, while allowing me to change the defcustom to ignore projectile
for my weird work monorepo.
Thanks!
With apologies to @MaskRay for having absolutely no luck with Projectile… I love the integrations, but they've given me nothing but grief on my work's monorepo.
Only falling back to
projectile-project-root
ifcquery--get-root
cannot find a valid compile_commands.json or .cquery by traversing upwards from the current directory.Allows cquery to work out-of-the-box for the following layout: