Ah awesome, thanks for the clarification! I think going forward I’ll prefer the background-indexer over clangd-indexer - since it sounds like it’s the future and I’d rather not use something that may soon be deprecated.
If you always want an up-to-date index and storing the shared snapshot is
just a performance optimization, use background-indexer.
Sharing the index was just a performance optimization, I think we may be able to avoid doing this for now. I outlined in a previous post that my team uses docker containers for development, and seeing as they are ephemeral, I didn’t want to be continually re-building the entire index across docker container start/stops. So this brings up another question: if we have a workflow where we
-
Start up a development container and clangd, building a background-index in the process.
-
Bring down said containers (but persisting the built index by e.g. a docker volume)
-
Bring up new containers with updated source code and mount the background index built by the previous docker run into the container (at the same path)
Is the background-indexer smart enough to do a rescan of the code base, and only update the files that changed? My assumption is yes, because the paths are the same and the digests(?) will be the same for the unchanged files, but confirmation here would be great.
Dex is an efficient implementation of running search queries (e.g. it models fuzzy-matching algorithm, > etc.).
Ah okay, so if I wanted to use the background-index and dex, are the only arguments I have to pass (in clang-8) -background-index and -use-dex-index?
Also one last question (sorry for the bombardment!), will background-index functionality be invokable by a separate binary in the future, or will it always be invoked by clangd? If we do want to build and share the index produced by the background-indexer in the future, it seems like the easiest way.
Thanks,
William