Frontend: add an additional search path for swift modules #42419
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 setups the frontend to search both an architecture suffixed and unsuffixed path. This improves the multi-architecture setup for Windows, enabling it use the directory form of the swift modules with the architectures overlaying in the swift module and leaving the arch suffixed directory for the import libraries. This can be fully generalized as this also enables Linux to use the multi-architecture search path for the swift modules enabling it to eventually adopt a SDK model as well.
|
@swift-ci please test |
|
@swift-ci please build toolchain windows platform |
compnerd
added a commit
to compnerd/swift-installer-scripts
that referenced
this pull request
Apr 18, 2022
Adjust the location of the swift modules to overlap across SDKs. The
directory form of the swift module can easily overlap and co-exist. Now
that the driver has learnt to scan the non-architecture dependent location
in addition to the architecture location dependent path, we can unify
the swiftmodule content in the SDK to a simpler layout. The layout now
is:
~~~
SDKROOT
`- usr
`- lib
`- swift
`- [platform]
+- [module].swiftmodule
| `- [triple].{swiftdoc,swiftmodule,swiftinterface}
`- [arch]
`- [import library]
~~~
On Windows, it would be preferable to further remove the intermediate
platform as we have that information earlier in the path.
Subsequent work remains to now ensure that the package manager will
similarly allow the XCTest swift modules to collapse.
While in theory it is possible to create a multi-architecture import
library, it is valuable to support user-selectable SDK installation
which requires that the we create the import libraries on the fly for
the selected architectures. It is more convenient from a distribution
perspective to simply make the content static and as such continue to
use the architect dependent directory for the import library unlike the
swift module.
This is dependent on swiftlang/swift#42419.
compnerd
added a commit
to compnerd/swift-driver
that referenced
this pull request
Apr 18, 2022
Now that the frontend properly consults the architecture independent path for the Swift modules, we can address the TODO that was left to be addressed. This requires swiftlang/swift#42419 and swiftlang/swift-installer-scripts#119
This was referenced Apr 18, 2022
compnerd
added a commit
to swiftlang/swift-installer-scripts
that referenced
this pull request
Apr 18, 2022
Adjust the location of the swift modules to overlap across SDKs. The
directory form of the swift module can easily overlap and co-exist. Now
that the driver has learnt to scan the non-architecture dependent location
in addition to the architecture location dependent path, we can unify
the swiftmodule content in the SDK to a simpler layout. The layout now
is:
~~~
SDKROOT
`- usr
`- lib
`- swift
`- [platform]
+- [module].swiftmodule
| `- [triple].{swiftdoc,swiftmodule,swiftinterface}
`- [arch]
`- [import library]
~~~
On Windows, it would be preferable to further remove the intermediate
platform as we have that information earlier in the path.
Subsequent work remains to now ensure that the package manager will
similarly allow the XCTest swift modules to collapse.
While in theory it is possible to create a multi-architecture import
library, it is valuable to support user-selectable SDK installation
which requires that the we create the import libraries on the fly for
the selected architectures. It is more convenient from a distribution
perspective to simply make the content static and as such continue to
use the architect dependent directory for the import library unlike the
swift module.
This is dependent on swiftlang/swift#42419.
compnerd
added a commit
to swiftlang/swift-installer-scripts
that referenced
this pull request
Jun 4, 2022
Adjust the location of the swift modules to overlap across SDKs. The
directory form of the swift module can easily overlap and co-exist. Now
that the driver has learnt to scan the non-architecture dependent location
in addition to the architecture location dependent path, we can unify
the swiftmodule content in the SDK to a simpler layout. The layout now
is:
~~~
SDKROOT
`- usr
`- lib
`- swift
`- [platform]
+- [module].swiftmodule
| `- [triple].{swiftdoc,swiftmodule,swiftinterface}
`- [arch]
`- [import library]
~~~
On Windows, it would be preferable to further remove the intermediate
platform as we have that information earlier in the path.
Subsequent work remains to now ensure that the package manager will
similarly allow the XCTest swift modules to collapse.
While in theory it is possible to create a multi-architecture import
library, it is valuable to support user-selectable SDK installation
which requires that the we create the import libraries on the fly for
the selected architectures. It is more convenient from a distribution
perspective to simply make the content static and as such continue to
use the architect dependent directory for the import library unlike the
swift module.
This is dependent on swiftlang/swift#42419.
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 setups the frontend to search both an architecture suffixed and
unsuffixed path. This improves the multi-architecture setup for
Windows, enabling it use the directory form of the swift modules with
the architectures overlaying in the swift module and leaving the arch
suffixed directory for the import libraries.
This can be fully generalized as this also enables Linux to use the
multi-architecture search path for the swift modules enabling it to
eventually adopt a SDK model as well.