Add support for dumping clang symbol graphs #5639
ethan-kusters2 years ago@daniel-grumberg is there anything specific we should be doing for these cases? I believe an umbrellaDirectory is just the include directory containing all public headers so we're likely already handling that correctly. I'm unsure about the custom module map file though.
daniel-grumberg2 years agoI don't think anything special needs to be done for umbrella directory layouts, since ExtractAPI works very similar to module builds. For a custom module map that is a bit more complicated, what information do we have about the custom module map?
ethan-kusters2 years ago (edited 2 years ago)For a custom module map that is a bit more complicated, what information do we have about the custom module map?
I think we just have the path to a module.modulemap file. This might be exclusively for system libraries actually: https://github.com/apple/swift-package-manager/blob/263171977ebcd47f4aaca1202cff5a96c5158a64/Documentation/Usage.md#import-system-libraries.
daniel-grumberg2 years agoI think this is only for system libraries as well, since this doesn't actually build anything if I read the docs right. I would just ignore it, documenting C/ObjC system library dependencies is outside the scope of this effort.
ethan-kusters2 years ago (edited 2 years ago)@daniel-grumberg it looks like -extract-api pretty prints its output by default. Is there a way to control that behavior?
daniel-grumberg2 years agoNo currently no, I can add a configuration option for that if you think it's useful
ethan-kusters2 years agoI'm happy either way – it seems like matching the default of the Swift Symbol Graph Extract tool might make sense for large frameworks where pretty-printing might actually make a noticeable affect on size? But I'll just remove this for now- something we can look at later on.
daniel-grumberg2 years agoYeah this isn't needed for the first version IMHO
| 132 | } | ||
| 133 | } | ||
| 134 | |||
| 135 | // FIXME: Does it matter for `-extract-api` usage if the target is C++ or not? | ||
| 136 | commandLine += try buildDescription.basicArguments(isCXX: nil) |
ethan-kusters2 years ago@daniel-grumberg should it matter if the target is C++ or not? The basicArguments() call adds some additional flags if so: https://github.com/apple/swift-package-manager/blob/fa91d29/Sources/Build/BuildPlan.swift#L417
daniel-grumberg2 years ago👍 1-extract-api doesn't support C++ at the moment anyway so it doesn't matter. We should find a way to error out if the user tries to generate a symbol graph for C++ code.
ethan-kusters2 years agoHere's an example of what the command line arguments contain when running swift package dump-symbol-graph on my machine for the sample project I attached in the description:
[
"/usr/bin/clang",
"-extract-api",
"--product-name=SampleObjCFramework",
"-o",
"/SampleObjCSwiftPackage/.build/x86_64-apple-macosx/symbolgraph/clang/SampleObjCFramework.symbols.json",
"-fobjc-arc",
"-target",
"x86_64-apple-macosx10.13",
"-g",
"-O0",
"-DSWIFT_PACKAGE=1",
"-DDEBUG=1",
"-fblocks",
"-index-store-path",
"/SampleObjCSwiftPackage/.build/x86_64-apple-macosx/debug/index/store",
"-fmodules",
"-fmodule-name=SampleObjCFramework",
"-I",
"/SampleObjCSwiftPackage/Sources/SampleObjCFramework/include",
"-fmodules-cache-path=/SampleObjCSwiftPackage/.build/x86_64-apple-macosx/debug/ModuleCache",
"-isysroot",
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk",
"-F",
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks",
"-fPIC",
"-x",
"objective-c-header",
"/SampleObjCSwiftPackage/Sources/SampleObjCFramework/include/SampleObjCFramework.h",
"/SampleObjCSwiftPackage/Sources/SampleObjCFramework/include/ImmutableRectangle.h",
"/SampleObjCSwiftPackage/Sources/SampleObjCFramework/include/ShapeCollection.h",
"/SampleObjCSwiftPackage/Sources/SampleObjCFramework/include/Triangle.h",
"/SampleObjCSwiftPackage/Sources/SampleObjCFramework/include/TwoDimensionalShape.h"
]daniel-grumberg2 years agoThat looks about right. I don't think we need -g, -O0 and -fPIC since we are only parsing ASTs but apart from that it seems correct.
ethan-kusters2 years agoI don't think we need -g, -O0 and -fPIC since we are only parsing ASTs but apart from that it seems correct.
Will those cause any issues or is it okay to keep the default behavior here?
daniel-grumberg2 years agoIt should be fine.
Add support for dumping clang symbol graphs
Looks fine to me.
Login to write a write a comment.
Adopt
clang -extract-apiin SwiftPM's existing symbol graph extraction infrastructure.Motivation:
This updates the
swift package dump-symbol-graphCLI to dump symbol graphs for packages that include clang targets and also enables documentation command plugins to request symbol graphs for clang targets.Modifications:
Added a branch in
SymbolGraphExtractto useclang -extract-apifor Clang targets instead of the Swift symbol graph extract tool.Also modifies the directory symbol graphs are emitted to so that Swift symbol graphs are placed in a
swiftsubdirectory and Clang symbol graphs are placed in aclangsubdirectory. This allows for future support of building mixed-language symbol graphs for a single target.Result:
SwiftPM can now successfully emit symbol graphs describing clang targets.
Testing:
Download the attached sample Objective-C Swift Package (based on the sample project from the extract-api announcement Forums Post)
Checkout this branch
Run: