HighCommander4 wrote:
> For multi-workspace (not vscode workspace) projects, say a monorepo where
> each subproject is built individually (and therefore separate build dirs and
> compile_commands.json), is the idea that each subproject will (should?) now
> have its own clangd instance running?
I would say this patch doesn't make any changes to how clangd works on, or
should be used with, such projects.
This patch is adding (the beginnings of) a non-default mode of operation
("strong workspace mode") that users need to opt into. If you don't opt into
it, everything will work just as it did before.
For a project of the sort you describe, even if you opt into "strong workspace
mode" (and after the remaining behaviours described in [this
comment](https://github.com/llvm/llvm-project/pull/155905#issuecomment-3549683238))
are implemented, not a lot is likely to change:
* If you don't have a `compile_commands.json` file in your workspace's root
directory, the new behaviour that clangd looks for such a file there even for
files outside the workspace directory is basically a no-op. Clangd will
continue using the sub-project `compile_commands.json` based on
ancestor-directory lookup just as it did before.
* Clangd will also look at a `.clangd` file in the workspace root, even for
files outside the workspace directory. That might be convenient (you can stash
some extra flags there that you want to apply for any file you open while
working on this project), but shouldn't make a big difference.
* The change to the working directory for fallback commands is probably not
relevant if you have `compile_comands.json` files.
> is the idea that each subproject will (should?) now have its own clangd
> instance running?
It has separately been proposed that clients like vscode-clangd gain the
ability to manager multiple clangd instances and launch one per "workspace
root" (in the sense of vscode's multi-root workspaces). For example, one such
proposal is being pursued in https://github.com/clangd/vscode-clangd/pull/810.
If such a proposal is accepted, then using it for a project of the sort you
describe (i.e. making each sub-project a "workspace root") would be a separate
knob you can opt into. I think it would come with both advantages and
disadvantages. (For example, clangd's index would no longer be able to
cross-reference symbols between sub-projects. Depending on how your
sub-projects are related, this may be a desirable change or an undesirable one.)
If you do opt into such a hypothetical multi-root workspace feature, you could
then _also_ opt into "strong workspace mode" for each sub-project, and that may
bring more benefits than using "strong workspace mode" with a single workspace
root for your overall project would have. (For example, if you have an ARM
sub-project and an x86 sub-project, and you open a system header from a source
file in your ARM sub-project, clangd will automatically use a compile command
from one of your ARM source files, more reliably than it does today.)
https://github.com/llvm/llvm-project/pull/155905
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
