ClangImporter: inject modulemaps via the VFS #63887
Conversation
compnerd
force-pushed
the
injection
branch
2 times, most recently
from
97a490e to
1158a55
Compare
|
@swift-ci please test |
|
@swift-ci please build toolchain windows platform |
|
@swift-ci please test |
| result.append(getLibStdCxxFileMapping(ctx)); | ||
| } | ||
|
|
||
| result.append(GetWindowsFileMappings(ctx)); |
There was a problem hiding this comment.
Would you mind splitting VC and WinSDK stuffs into separate functions? They come from different places and use completely distinct searching strategies.
There was a problem hiding this comment.
I would rather that we don't do that. This function really should just call the platform specific handler for any of the platforms required, ideally pushing the platform check here instead of inside the function. Splitting up the function internally is possible, but seems like it doesn't aid clarity.
|
I wonder if it would be better to construct a Clang driver, use it to find a It seems libstdc++ mapping already uses similar pattern, so I guess it’s possible and won’t regress the performance too much. |
The toolchain is internal to clang, so we cannot instantiate it that way. I think that computing the paths is better than trying to find a random header, specially with differences in header lookups across Windows and other platforms. |
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please build toolchain Windows platform |
|
Ah right, I missed the changes to build-windows-toolchain.bat, which is why I wanted the development workflow addressed separately and initially. |
|
@swift-ci please build toolchain windows platform |
This is the second step towards removal of the content injection into the Visual Studio installation. With this the new path is enabled to create the mappings to the SDK shared content. Subsequent improvements involve the introduction of new options to the Swift driver and Swift frontend: 1. `-windows-sdk-root` 2. `-windows-sdk-version` 3. `-visualc-tools-root` 4. `-visualc-tools-version` The introduction of these options will then feed into the path selection here enabling granular control over the VCRuntime and Windows SDK by the user. Thanks to @artemcm for the very helpful discussion and help on identifying a good set of options for the driver. Thanks to @stevapple for the inspiration for this patch.
|
Please test with following PRs: @swift-ci please build toolchain windows platform |
|
Please test with following PRs: @swift-ci please build toolchain windows platform |
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
|
@swift-ci please test Linux platform |
1 similar comment
|
@swift-ci please test Linux platform |
|
@swift-ci please test Linux platform |
|
Going to merge this for now so we can start experimenting with removing the CustomActions. |
With swiftlang#63887, the swift compiler can dynamically inject the VFS overlay paths to add the modulemaps and apinotes for the Windows SDK. This obviates the need for the custom action in the SDK installation. Update the build rules to account for this along with swiftlang/swift-installer-scripts#176.
This is the second step towards removal of the content injection into the Visual Studio installation. With this the new path is enabled to create the mappings to the SDK shared content. Subsequent improvements involve the introduction of new options to the Swift driver and Swift frontend:
-windows-sdk-root-windows-sdk-version-visualc-tools-root-visualc-tools-versionThe introduction of these options will then feed into the path selection here enabling granular control over the VCRuntime and Windows SDK by the user.
Thanks to @artemcm for the very helpful discussion and help on
identifying a good set of options for the driver. Thanks to @stevapple
for the inspiration for this patch.