arphaman added a comment. In https://reviews.llvm.org/D49523#1167553, @malaperle wrote:
> Interesting! We also have a need for passing compilation commands in a > context where there is no compile_commands.json, but we were thinking of > putting this in a "didChangeConfiguration" message so that all the commands > would be available even before files are opened. This would be allow Clangd > to have the necessary information for background indexing which would include > unopened files. Subsequent changes to compilation commands would probably go > through a similar didChangeConfiguration and the appropriate (opened) files > would get reparsed (not unlike https://reviews.llvm.org/D49267). I'm making a > few guesses here: I assume that in the context of XCode, you would not do > background indexing in Clangd but let XCode do it as it can also coordinate > (and not overlap) with build tasks. Is that correct? In any case, I think the > approach in the patch is not incompatible with what we had in mind, i.e. we > could also reuse "overrideCompilationCommandForFile" for each file specified > in didChangeConfiguration. I'm point this out because if you *do* end up > needing all the compilation commands beforehand like I mentioned, then maybe > we can skip the approach of specifying them with didOpen and send them all > with didChangeConfiguration from start. Thanks for your response, As it stands right now we will not run the indexer in Clangd for our use case, and it's unclear if we can even assemble a set of compile commands, so we would like to provide the commands when a file is open. We might be interested in a "didChangeConfiguration" message extension in the future (ideally it would be possible to change the subset of the constructed compilation database). Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D49523 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
