WiX: remove extraneous architecture in search path #119
Conversation
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.
|
While I’m delighted by the change, we had better first have it reflected in the CMake scripts for core libraries. Unix (Linux) always supports multi-arch Swift library bundle, and I’ve taken a try on swiftlang/swift#41850 to align the runtime library layout of Windows and Unix. This will further enable us to have portable and multi-arch SDKs with unified layout. Discussion thread: https://forums.swift.org/t/misplacement-of-runtime-libraries-on-linux/55888 |
|
The CMake build already does this correctly, this is undoing the need for the workaround of moving the content around at packaging time. Also note that this does not touch the runtime at all - it is purely at the SDK level. Edit: Wait, do you mean in swift-corelibs-{libdispatch,foundation,xctest}? |
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
Exactly. |
|
What do you think would be good to change there? I don't mind doing that subsequently (this change is already complicated enough - its across 3 different repositories). |
|
It’s nice to hear that’s going to be addressed. Sequence is not so important, and go ahead 🚀 Hmmm… Maybe I need to explain a bit. I’m more in favor of leaving the layout as-is during packaging (that is, preserve the layout of what CMake installs), so I’m curious if the CMake work is done for core libraries. |
|
Ah, I see. Yes, I agree, it would be nice if CMake installed the files in the final location. I can do those changes subsequently. However, longer term, I want to get rid of that and use |
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:
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.