Merge main into release/6.3
#9534
Draft
+484
−301
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Set the `SWIFT_FORCE_STATIC_LINK_STDLIB` build setting in SwiftBuild accordingly to the command line argument and if it's not on Darwin. In addition, set the SWIFT_RESOURCE_DIR setting as that is what the Native build system does. Fixes: #9320 Issue: rdar://163948614 Depends on: #9389 Needs: swiftlang/swift-build#942
…ot build-time, search path (#9518) This constrains a behavior I landed in #8199 so that it only includes the `PrivateFrameworks` directory from Xcode's platform directory (when present) as a **runtime** framework search path (via `DYLD_FRAMEWORK_PATH`) and no longer includes it as a _build-time_ framework search path (via `-F <path>`). ### Motivation: This is a follow-up to a change I made in #8199. Those changes had an undesirable side effect of including private frameworks in all builds, and means that when those frameworks are present at build time, they're included in client builds and can be `import`'ed or linked. Exposing those frameworks to clients at _build-time_ was not intended, and can cause unexpected results or failures if (for example) those private frameworks themselves contain unresolvable module imports. However, platform private frameworks directories _should_ continue to be included in runtime framework search paths, so they can be located and loaded when referenced by public frameworks/libraries. ### Modifications: - Introduce separate properties for build-time vs. runtime framework and library search paths, so the two categories can be differentiated by callers. - Omit the private frameworks search path from the new build-time frameworks property. - Adopt the relevant new properties at both build and runtime usage sites. ### Result: After this change, I validated that: - a local package build no longer contains the private frameworks search path entry at build time, using `swift build --build-tests --verbose`, and - a local package test operation still includes the search path, using `env DYLD_PRINT_ENV=1 swift test`.
Fix various tests so they pass on Windows - also mark withKnownIssues tests as isIntermittent: true so that as we fix things in dependent packages (like swift-build) we don't break swiftPM CI
Adopt the new API on SWBBuildRequest Depends on #9417 Fixes: #9321 --------- Co-authored-by: Bassam Khouri <[email protected]>
This ensures that targets know to re-request the list of targets when the underlyinf Swift Build server regenerates the build description
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR was automatically opened by a GitHub action. Review the changes included in this PR and determine if they should be included in the release branch. If yes, merge the PR. Otherwise revert changes that should not be included on this branch.