Add proper support for custom Swift toolchains #1025
Merged
Conversation
This file contains 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
keith
added a commit
to bazelbuild/apple_support
that referenced
this pull request
Mar 21, 2023
This adds support for replacing the __BAZEL_CUSTOM_XCODE_TOOLCHAIN_PATH__ argument with the absolute path to the custom toolchain defined by the TOOLCHAINS environment variable (passed with --action_env). This allows us to fully support custom Swift toolchains and linking their libraries bazelbuild/rules_swift#1025
Previously we did some amount of handling if you passed a custom toolchain identifier. This didn't handle the case that the toolchain required new compatibility libraries to actually link your binary. To handle this we have to pass a new -L to the path in the root of the toolchain. We do this with a custom env var that we replace, similar to the DEVELOPER_DIR variable. Ideally this would be cached in memory, but we can't do that without editing bazel, luckily xcrun has a cache that makes this likely fast enough (about 0.01s for a cached invocation).
keith
force-pushed
the
ks/add-proper-support-for-custom-swift-toolchains
branch
from
881bbe2
to
b301b5c
Compare
brentleyjones
approved these changes
Mar 22, 2023
brentleyjones
approved these changes
Mar 22, 2023
keith
requested review from
BalestraPatrick,
segiddins,
thii and
mattrobmattrob
as code owners
keith
added a commit
to bazelbuild/apple_support
that referenced
this pull request
Mar 22, 2023
This adds support for replacing the `__BAZEL_CUSTOM_XCODE_TOOLCHAIN_PATH__` argument with the absolute path to the custom toolchain defined by the TOOLCHAINS environment variable (passed with --action_env). This allows us to fully support custom Swift toolchains and linking their libraries bazelbuild/rules_swift#1025
tymurmustafaiev
pushed a commit
to tymurmustafaiev/rules_swift
that referenced
this pull request
Jul 19, 2023
Previously we did some amount of handling if you passed a custom toolchain identifier. This didn't handle the case that the toolchain required new compatibility libraries to actually link your binary. To handle this we have to pass a new -L to the path in the root of the toolchain. We do this with a custom env var that we replace, similar to the DEVELOPER_DIR variable. Ideally this would be cached in memory, but we can't do that without editing bazel, luckily xcrun has a cache that makes this likely fast enough (about 0.01s for a cached invocation).
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.
Previously we did some amount of handling if you passed a custom
toolchain identifier. This didn't handle the case that the toolchain
required new compatibility libraries to actually link your binary. To
handle this we have to pass a new -L to the path in the root of the
toolchain. We do this with a custom env var that we replace, similar to
the DEVELOPER_DIR variable. Ideally this would be cached in memory, but
we can't do that without editing bazel, luckily xcrun has a cache that
makes this likely fast enough (about 0.01s for a cached invocation).