Don't link runtime compatibility library in pure Clang targets. #2134
Conversation
|
Please test with following pull request: @swift-ci Please test |
|
|
||
| /// True if this product contains Swift targets. | ||
| public var containsSwiftTargets: Bool { | ||
| return targets.contains { $0.underlyingTarget is SwiftTarget } |
There was a problem hiding this comment.
It looks like this is just top-level targets; should it search for any targets?
There was a problem hiding this comment.
Yeah, you probably want to flatMap the recursiveDependencies first. Something like:
targets.flatMap { $0.recursiveDependencies }.contains { $0.underlyingTarget is SwiftTarget }
There was a problem hiding this comment.
Not sure if target.lazy.flatMap will help with performance here?
There was a problem hiding this comment.
There's no reason to build a temporary here, so lazy would work, or targets.contains { $0.recursiveDependencies.contains { ... } }
There was a problem hiding this comment.
One complications here is that we should be stopping this search at the first dynamic product in the dependency graph because the top-level product could be just made up of C targets and getting Swift targets via a dylib.
There was a problem hiding this comment.
One thing though is that C targets can't import Swift targets in SwiftPM (at least not right now), so we can just do this for the top-level targets (as you've already done) and handle the other complications when we do start supporting the other case. Can you add a comment and file a JIRA for that?
There was a problem hiding this comment.
swiftlang/swift#25030 introduces a compatibility library that can be statically linked into binaries in order to back-deploy runtime fixes and new features to OSes that shipped with older Swift runtimes. This library depends on the Swift runtime being linked into the executable, so it will cause link errors for pure Clang products (and even if it didn't, it would be a waste of code size). When building a product without any Swift in it, ask Swift to drive the linker without introducing any runtime compatibility libraries (and shake out a few other unnecessary linker flags while we're here). rdar://problem/50057445
jckarter
force-pushed
the
runtime-compat-lib-clang-targets
branch
from
86df6bb to
1a35ac7
Compare
|
@swift-ci Please smoke test |
|
Please test with following pull request: @swift-ci Please smoke test |
|
@aciidb0mb3r This look OK for now? |
|
Yep, this looks good! |
swiftlang/swift#25030 introduces a compatibility library that can be statically linked into binaries
in order to back-deploy runtime fixes and new features to OSes that shipped with older Swift
runtimes. This library depends on the Swift runtime being linked into the executable, so it will
cause link errors for pure Clang products (and even if it didn't, it would be a waste of code
size). When building a product without any Swift in it, ask Swift to drive the linker without
introducing any runtime compatibility libraries (and shake out a few other unnecessary linker
flags while we're here).
rdar://problem/50057445