build: Install libraries in an arch sub-folder

[Steelskin]

This is the proper installation scheme for Swift libraries on Windows and prevents having to manually copy them in build.ps1.

[Steelskin]

@swift-ci please test

[finagolfin]

I tried to implement this years ago, swiftlang/swift#63645, but was told that it was preferred to switch to a whole new triple-named resource directory scheme, so this approach was rejected. Would you and @compnerd be interested in collaborating on switching Swift resource directories to that, ie usr/lib/swift/android/aarch64/ would transition to usr/lib/swift/aarch64-linux-android/? I don't think it's too much work, the main issue is settling on what triples to use.

[Steelskin]

I tried to implement this years ago, swiftlang/swift#63645, but was told that it was preferred to switch to a whole new triple-named resource directory scheme, so this approach was rejected. Would you and @compnerd be interested in collaborating on switching Swift resource directories to that, ie usr/lib/swift/android/aarch64/ would transition to usr/lib/swift/aarch64-linux-android/? I don't think it's too much work, the main issue is settling on what triples to use.

Thanks for the context. It would be great if we could talk more offline about this. I do not have a strong feeling on which directory is better but changing to a triple would be a large change for the Windows installer - and I believe there are some swift-driver changes involves too.

In the meantime, I can add a toggle for this so it only takes effect for the Windows build. WDYT?

[finagolfin]

Sure, I think Saleem switched Windows to this approach a long time ago, but when I tried to do the same with Unix, that wasn't accepted.

Note that I'm not against this approach, particularly since I pushed it in the past myself, just pointing out that it was blocked before.

Who knows, maybe Evan has since changed his mind? Maybe have Saleem talk to him and see.

[compnerd]

Well, I think that we don't want to put more stuff in the resource directory - we should be putting less there. But the layout itself of the SDK, we can discuss. I think that the triple based one might not be as useful once we have platform specific SDKs. But, we can follow up with that separately. In the mean time, I think that adding the option to opt into the thick module appropriate layout shouldn't be a real concern - it is opt-in after all.

Migrating the other platforms to this layout would certainly be good, but making the changes to build-script is the challenge.

[finagolfin]

Well, I think that we don't want to put more stuff in the resource directory - we should be putting less there.

This has nothing to do with what to put in the resource directory, a simple rename is all we're discussing.

the triple based one might not be as useful once we have platform specific SDKs.

Not sure what you're referring to here, some other reorg underway?

In the mean time, I think that adding the option to opt into the thick module appropriate layout shouldn't be a real concern - it is opt-in after all.

No idea what you mean here, this pull is about moving the runtime libraries to arch-specific directories, nothing to do with modules.

Migrating the other platforms to this layout would certainly be good, but making the changes to build-script is the challenge.

It is pretty easy, see my pulls from a couple years ago linked above. Unfortunately, Evan rejected it for non-Darwin platforms at the time. 🫤

[compnerd]

Well, I think that we don't want to put more stuff in the resource directory - we should be putting less there.

This has nothing to do with what to put in the resource directory, a simple rename is all we're discussing.

👍

the triple based one might not be as useful once we have platform specific SDKs.

Not sure what you're referring to here, some other reorg underway?

No, more the idea that we could move Linux towards what Windows and macOS already do.

In the mean time, I think that adding the option to opt into the thick module appropriate layout shouldn't be a real concern - it is opt-in after all.

No idea what you mean here, this pull is about moving the runtime libraries to arch-specific directories, nothing to do with modules.

Right, I'm saying that this is to support the thick modules usage on Windows. The import libraries are what this really is about moving. The runtime is split and not embedded into the SDK.

Migrating the other platforms to this layout would certainly be good, but making the changes to build-script is the challenge.

It is pretty easy, see my pulls from a couple years ago linked above. Unfortunately, Evan rejected it for non-Darwin platforms at the time. 🫤

[finagolfin]

Right, I'm saying that this is to support the thick modules usage on Windows. The import libraries are what this really is about moving. The runtime is split and not embedded into the SDK.

OK, so this pull only affects Windows? I thought you were moving the libraries on Unix also, so I was just warning Fabrice about the opposition I faced before. To be clear, I am all for moving these Swift libraries to arch-specific directories on all non-Darwin platforms, so please don't see my comments here as hindering you in any way.

[compnerd]

Yes, these changes, while generic, are meant for Windows. The default is to continue to use the existing layout, but you can opt-in via -D .... to install into the architecture subdirectory.

[Steelskin]

I need to update this PR to do the same thing that swiftlang/swift-corelibs-libdispatch#889 does, to add the CMake option for it. I'll get to it soon.
I was under the mistaken impression that all systems used the same layout when I opened this PR, I'll fix it.

[Steelskin]

@swift-ci please smoke test

[Steelskin]

I started a toolchain build on swiftlang/swift#84014