-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add support for compilation databases #2962
Add support for compilation databases #2962
Conversation
This is an early draft, I haven't added tests and some changes should be refactored. |
Generated by 🚫 Danger |
I don't see any tests related to |
@kastiglione |
This looks great, Dave! I wanted to take a stab at adding a test target for the With this in mind, I'm ok merging this as-is without tests since that's (unfortunately) in line with the rest of what we have in Let me know when you're done with this and I can merge. |
Thanks for reviewing and checking into the tests. I'll convert this out of Draft and ping you when it's ready. |
Ready, thanks! |
return nil | ||
} | ||
|
||
// Convert the compilation database to a dictionary, with source files as keys and compiler arguments as values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A note about this dictionary. It could use quite a lot of redundant memory for large modules. For each file in a module, there will be a single compiler invocation (which covers each file in the module). For example:
swiftc --yada --yada File1.swift File2.swift ... FileN.swift
This command line will be copied N times, one for each path in the module. In theory, the same array could be shared for each file in the module. Array deduping (or string interning) would reduce the memory here.
Just wanted to make a note of this.
Just curious, @kastiglione How are you going to receive compilation database files? |
We have a tool to generate compilation databases for Bazel projects. I would like to open source it, but even then it's use is limited to Bazel projects. It's doable to generate a compilation database from an xcodebuild log. The json structure is straight forward. |
Talking to Dave, it occurred to us that if we standardized SourceKitten/SwiftLint to use the compilation database format as input whenever we need to deal with SourceKit compiler arguments, that could simplify and standardize working with a variety of build tools, such as Xcode, bazel, SwiftPM and CMake. |
👋 @kastiglione I see the compilation database json that swiftlint takes should have an array of dictionaries with |
@acecilia i don't recall the history here, but i imagine we could make both work if you have another tool that does the traditional format. probably just have to be careful about space escapes |
Thanks. I end up adapting my tool to the existing format |
This is to add support for compilation databases (aka
compile_commands.json
) as an alternative to parsing compiler invocations from a build log.A compilation database can be passed using the newly added
--compile-commands
flag. This new flag is mutually exclusive to--compiler-log-path
.TODO
Add tests