[APIDigester] Build the API digester as a frontend tool instead of a standalone executable #36381
Conversation
|
@swift-ci please smoke test |
|
@swift-ci please build toolchain |
…standalone executable
owenv
force-pushed
the
api-digester-as-frontend-tool
branch
from
5b58cb6
to
77efd77
Compare
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
|
@swift-ci please smoke test macOS |
|
@swift-ci please smoke test Linux |
|
Hmm, these lldb failures seem unrelated |
|
This is a great idea, Thanks, @owenv ! |
|
@swift-ci please smoke test |
|
@swift-ci please build toolchain |
|
Linux Toolchain (Ubuntu 16.04) Install command |
|
@swift-ci please build toolchain macOS |
1 similar comment
|
@swift-ci please build toolchain macOS |
|
I think the watchOS failure is fixed now @swift-ci please build toolchain macOS |
|
macOS Toolchain Install command |
|
I tried the toolchain out locally and everything seemed to be working. I think this is good to go now, as long as it's ok to keep the FrameworkABIBaseline data in the toolchain-tools component, which I don't expect to cause any problems |
|
@swift-ci please smoke test and merge |
In apple#36381 the swift-api-digester changed from being a standalone tool to be a symlink of the frontend. With the symlink, the target swift-api-checker disappeared. In order to keep depending on symlink_abi_checker_data for the tests, change the mentions of swift-api-checker to swift-frontend (which is the actual target that creates the symlink).
In #36381 the swift-api-digester changed from being a standalone tool to be a symlink of the frontend. With the symlink, the target swift-api-checker disappeared. In order to keep depending on symlink_abi_checker_data for the tests, change the mentions of swift-api-checker to swift-frontend (which is the actual target that creates the symlink).
This reduces the install size of the toolchain by around 10% depending on the platform and configuration. Because the api digester now has virtually no size overhead, I moved it from the
toolchain-toolscomponent tocompiler. If there's a reason to continue excluding it from some toolchains I can revert that change though.For now, api-digester still uses llvm::cl based option parsing, but I'd like to migrate it to use the frontend option tables eventually for consistency with the other tools. There's also probably some opportunities to refactor code out of swift_api_digester_main.cpp, I haven't looked into that too much yet.