Allow -explicit-swift-module-map-file without full explicit module build #39887
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
This enables the use of `-explicit-swift-module-map-file` for some modules in the build, while still loading implicit modules as before. This is useful to improve the performance of builds with many modules to avoid searching many different directories pass with `-I`. Previously VFS overlays could be used for this use case as well, but it seems valuable to unify on the same infrastructure used for explicit module builds.
|
@swift-ci test |
artemcm
approved these changes
Dec 3, 2021
nkcsgexi
approved these changes
Dec 3, 2021
|
@artemcm thoughts on partially explicit module build? |
keith
deleted the
ks/allow-explicit-swift-module-map-file-without-full-explicit-module-build
branch
|
Thanks! |
keith
added a commit
to bazelbuild/rules_swift
that referenced
this pull request
Feb 12, 2022
As of Swift 5.6 and this PR swiftlang/swift#39887 the new json format used for entirely explicit module builds can be used without entirely disabling implicit modules. This provides an alternative to VFS overlays for discovering dependencies without `-I` search paths. This is theoretically about the same but I expect this file format to have better support in general than VFS overlays for things like the new incremental compilation support, which currently doesn't support VFS overlays, and this shouldn't have any downsides vs VFS files. This format does support some more keys than just the 2 we pass, as far as I can tell they are unused today, so I'm opting not to pass them. We may have to revisit this in the future.
keith
added a commit
to bazelbuild/rules_swift
that referenced
this pull request
Apr 25, 2022
As of Swift 5.6 and this PR swiftlang/swift#39887 the new json format used for entirely explicit module builds can be used without entirely disabling implicit modules. This provides an alternative to VFS overlays for discovering dependencies without `-I` search paths. This is theoretically about the same but I expect this file format to have better support in general than VFS overlays for things like the new incremental compilation support, which currently doesn't support VFS overlays, and this shouldn't have any downsides vs VFS files. This format does support some more keys than just the 2 we pass, as far as I can tell they are unused today, so I'm opting not to pass them. We may have to revisit this in the future.
keith
added a commit
to bazelbuild/rules_swift
that referenced
this pull request
Oct 10, 2022
As of Swift 5.6 and this PR swiftlang/swift#39887 the new json format used for entirely explicit module builds can be used without entirely disabling implicit modules. This provides an alternative to VFS overlays for discovering dependencies without `-I` search paths. This is theoretically about the same but I expect this file format to have better support in general than VFS overlays for things like the new incremental compilation support, which currently doesn't support VFS overlays, and this shouldn't have any downsides vs VFS files. This format does support some more keys than just the 2 we pass, as far as I can tell they are unused today, so I'm opting not to pass them. We may have to revisit this in the future. This kind of cherry picks 1666670 but I kept the VFS feature for now for legacy users.
tymurmustafaiev
pushed a commit
to tymurmustafaiev/rules_swift
that referenced
this pull request
Jul 19, 2023
As of Swift 5.6 and this PR swiftlang/swift#39887 the new json format used for entirely explicit module builds can be used without entirely disabling implicit modules. This provides an alternative to VFS overlays for discovering dependencies without `-I` search paths. This is theoretically about the same but I expect this file format to have better support in general than VFS overlays for things like the new incremental compilation support, which currently doesn't support VFS overlays, and this shouldn't have any downsides vs VFS files. This format does support some more keys than just the 2 we pass, as far as I can tell they are unused today, so I'm opting not to pass them. We may have to revisit this in the future. This kind of cherry picks 1666670 but I kept the VFS feature for now for legacy users.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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 enables the use of
-explicit-swift-module-map-filefor somemodules in the build, while still loading implicit modules as before.
This is useful to improve the performance of builds with many modules to
avoid searching many different directories pass with
-I. PreviouslyVFS overlays could be used for this use case as well, but it seems
valuable to unify on the same infrastructure used for explicit module
builds.