Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-2047] [llbuild] Add support for Clang compilation database #799

Open
ddunbar opened this issue Jul 11, 2016 · 2 comments
Open

[SR-2047] [llbuild] Add support for Clang compilation database #799

ddunbar opened this issue Jul 11, 2016 · 2 comments

Comments

@ddunbar
Copy link
Member

ddunbar commented Jul 11, 2016

Previous ID SR-2047
Radar None
Original Reporter @ddunbar
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s llbuild
Labels Improvement
Assignee None
Priority Medium

md5: f0b3742444cec6af798afdf65cdd1da2

Issue 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.

@ddunbar
Copy link
Member Author

ddunbar commented Jul 11, 2016

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.

@ddunbar
Copy link
Member Author

ddunbar commented Jul 11, 2016

/cc @akyrtzi

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant