================
@@ -45,6 +45,10 @@ class GlobalCompilationDatabase {
return std::nullopt;
}
+ virtual std::vector<std::string> getAllFilesInProjectOf(PathRef File) const {
----------------
sam-mccall wrote:
The layering here looks close, but not quite right to me.
Rather than having GCDB expose "get all files" and building module-scanning on
top of that, I think GCDB should expose module data: e.g. through a subobject
interface like `shared_ptr<ProjectModules>
GlobalCDB::getModulesDatabase(PathRef File)`, returning something like the
current ModulesDependencyScanner behind an interface.
(If the interface to ModuleDependencyScanner was narrower, it could also expose
those queries directly)
Reasons to prefer this:
- suppose we augment `compile_commands.json` with some module manifest, now we
want to use a different strategy for the projects that have one - which is
something we only know inside DirectoryBasedCDB
- GlobalCDB is our general "build system integration" point - if we need to
swap out the high level "what are the projects and how do we talk to their
build systems" strategy, we likely need to reconsider module discovery too
- getAllFilesInProjectOf exposes more internal structure than I'd like for
general GlobalCDB: we use this abstraction to integrate in cases where there's
no "project" structure *and* source files are not enumerable
https://github.com/llvm/llvm-project/pull/66462
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
