As it is highly possible that Xcode 15 beta (expected on in a week, on Jun 5th) will no longer support SWIFT_USE_INTEGRATED_DRIVER: NO, we should be ready to add support for the integrated driver.
This is a first PR that refactors the existing implementation so it the swift-driver PR will be easier to reason about.
This PR doesn't change anything in the business logic.
Includes:
Adds a mode in the BuildSettingsIntegrateAppender to specify if the SWIFT_USE_INTEGRATED_DRIVER should be added or not (for now, always add)
Splits Swiftc into 2 phases: emit module and compilation. With swiftc, this is always done in a single process (at least from XCRemoteCache's perspective), in the driver world, that will be 2 independent processes
Adds extra options for the input (*.swift) and output (.d, .o etc) files: either via a file (used currently) or explicitly in the cmd argument list
XCSwiftc's logic is broken down to the XCSwiftAbstract, which will be shared with the XCSwiftFrontend
Making some params optional, which are nil in the swift-frontend
As it is highly possible that Xcode 15 beta (expected on in a week, on Jun 5th) will no longer support
SWIFT_USE_INTEGRATED_DRIVER: NO
, we should be ready to add support for the integrated driver.This is a first PR that refactors the existing implementation so it the swift-driver PR will be easier to reason about.
This PR doesn't change anything in the business logic.
Includes:
BuildSettingsIntegrateAppender
to specify if theSWIFT_USE_INTEGRATED_DRIVER
should be added or not (for now, always add)swiftc
, this is always done in a single process (at least from XCRemoteCache's perspective), in the driver world, that will be 2 independent processes*.swift
) and output (.d, .o etc) files: either via a file (used currently) or explicitly in the cmd argument listXCSwiftc
's logic is broken down to theXCSwiftAbstract
, which will be shared with theXCSwiftFrontend
nil
in the swift-frontendNext steps
Add swift-frontend support (draft PR)