ddunbar
commented
8 years ago This is more subtle than one might think. Unlike most build systems, llbuild is designed as a library for building build systems, and unlike make, ninja, etc. it doesn't have a built-in expectation that the tasks it executes are subprocesses. However, the Clang compilation database is really tied to what subprocesses are invoked (and wouldn't have a way to express a more subtle notion of a task).
What this means as far as this bug is that this feature doesn't slot in naturally to the existing API decomposition. We do have an abstraction around the thing that is responsible for executing all subprocesses on behalf of an llbuild-based build system (that is the BuildExecutionQueue). Implementing this "probably" means adding support to the implementors of that interface for logging all of the subprocesses tasks in the compilation database format, and then plumbing through options to support initializing it appropriately.
Of course, this approach will then immediately break if any client of llbuild moves to using in-process execution of tasks that other clients expected to be in the compilation database, but that is probably not something likely to happen in the short term, and can't be avoided without using a radically different architecture for the entire problem.
Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | llbuild | |Labels | Improvement | |Assignee | None | |Priority | Medium | md5: f0b3742444cec6af798afdf65cdd1da2Issue Description:
The Clang compilation database format:
http://clang.llvm.org/docs/JSONCompilationDatabase.html
is a useful way for external tools to be able to introspect on part of a build process. llbuild should have built-in support for it.