Should I have a different index for every toolchain? #2607
Replies: 1 comment
I think any problems are likely to be limited to information about toolchain-specific code in the index being inaccurate or out of date.
Looking at the code, it's just a hash of the file's full path, so no.
I think that's a tradeoff of additional configuration overhead and indexing time on the one hand, versus index accuracy (particularly when it comes to toolchain-specific code). I probably wouldn't bother unless I spent significant time developing toolchain-specific code, in which case I would. |
Uh oh!
There was an error while loading. Please reload this page.
I use clangd via vscode-clangd. For it to be able to find the compilation database created by CMake, I use cmake.copyCompileCommands to copy it to the root of my project sources.
Now, I build this project with different toolchains. gcc/clang, x86, arm, mips. In fact, each toolchain even uses different CMake options to enable/disable features in the code via the preprocessor, so even the same source file is "different" (at least after the preprocessor has done its job).
I don't worry too much about this. ccache takes into consideration all the options, and even the compiler in use; so I didn't even stop to think about whether clangd does the same.
Since I always copy the compilation database in the same place, independently of toolchain, the index cache is always in the same place. I am going to cause problem by doing this? I see the cache is formed by <file_name>.<hexadecimal_value>.idx. Does this "<hexadecimal_value>" already take care of the compiler/defines differences, as with ccache?
In short, should I start to put the compilation database in a toolchain/compiler/build-specific location?
All reactions