Begin installing textual .swiftinterface instead of binary .swiftmodule in toolchain builds for non-Apple platforms

[stmontgomery]

This modifies the CMake rules to begin installing textual .swiftinterface files instead of binary .swiftmodule files when performing a toolchain build for non-Apple platforms.

Checklist:

• Code and documentation should follow the style of the Style Guide.
• If public symbols are renamed or modified, DocC references should be updated.

Fixes rdar://140587787

[stmontgomery]

@swift-ci please test

[grynspan]

@compnerd Any concerns?

[stmontgomery]

@compnerd I am aware this will conflict with your pending PR (#971), and I can wait to land mine if you think yours is going to land soon.

[compnerd]

Fortunately, I decided to cross-repo test it before merging. It seems that something needs a small tweak, so lets go ahead and merge this change, I'll rebase my change subsequently.

[compnerd]

@compnerd Any concerns?

I do have one - I have recently seen that textual interfaces are a problem for Android. We should ideally do a cross-repo test with this PR as well to ensure that the Windows builds would not break due to the inability to build the module from the textual interface.

[stmontgomery]

I did cross-repo toolchain and smoke test builds—see swiftlang/swift#79678 for results. From what I could tell, Windows failed due to an unrelated reason. And I'm not sure any of those build or test Android? Plus, I'm not sure any of those Swift CI tests actually validate that Swift Testing's module can be built by a client. Because of this, I am planning to validate this once it lands in toolchains.

[stmontgomery]

I'm not aware of Swift Testing being included in toolchains for any platforms other than macOS, Linux, and Windows. Do you know otherwise, @compnerd? (Mainly asking about Android.)

[compnerd]

I did cross-repo toolchain and smoke test builds—see swiftlang/swift#79678 for results. From what I could tell, Windows failed due to an unrelated reason. And I'm not sure any of those build or test Android? Plus, I'm not sure any of those Swift CI tests actually validate that Swift Testing's module can be built by a client. Because of this, I am planning to validate this once it lands in toolchains.

That is a very related failure :) The packaging failed due to the missing modules which are being shipped to users.

https://github.com/swiftlang/swift-installer-scripts/blob/main/platforms/Windows/sdk/win/sdk.wxs#L156-L161
https://github.com/swiftlang/swift-installer-scripts/blob/main/platforms/Windows/sdk/drd/sdk.wxs#L163-L168

We need to update the packaging rules to ensure that the right files are being shipped to the users.

I'm not aware of Swift Testing being included in toolchains for any platforms other than macOS, Linux, and Windows. Do you know otherwise, @compnerd? (Mainly asking about Android.)

The Browser Company is building swift-testing for Android in CI nightly. There are logs from a recent run. There have been a few other issues that are currently breaking the CI that are being investigated that are unrelated to Testing.

[stmontgomery]

Thanks! I will submit a PR to swift-installer-scripts to adjust those paths and re-run cross-repo CI to validate.

I'm still not sure whether there exist any tests which run as part of those Swift CI jobs that attempt to import Testing and validate that the module is usable. (Our own tests in this repo do that, but right now they don't build in Swift CI or via CMake.)

[finagolfin]

My Android SDK bundle also started cross-compiling this repo to Android last week, both with the upcoming 6.1 release branch and trunk 6.2, finagolfin/swift-android-sdk@eb1567b1c. Cross-compiling Testing tests for a Swift package with the 6.1 Android SDK bundle works fine.

I also built this repo natively on Android and was able to run its tests, with only two deprecated tests failing, then use this Testing library as part of a native Android Swift 6.2 toolchain to build and run the Testing tests for swift-png, no problem.

I am currently looking for a good candidate for a Swift package that primarily uses Testing-based tests to add to my daily Android CI, to make sure this Testing library is continually checked in the Android emulator.

[grynspan]

was able to run its tests, with only two deprecated tests failing

Anything there we need to fix?

[stmontgomery]

@compnerd Did you have any remaining concerns about this, now that the cross-repo CI build is succeeding? I'd like to merge this and swiftlang/swift-installer-scripts#395 tomorrow if not.

[finagolfin]

Anything there we need to fix?

I doubt it, once I saw that both were marked experimental and deprecated, I lost any interest in investigating. I only mentioned them for completeness, just ran the tests again and here were the two failures natively on Android:

✘ Test v0_experimental() recorded an issue at ABIEntryPointTests.swift:57:11: Expectation failed:
symbol(in: testingLibrary, named: "swt_copyABIEntryPoint_v0").map {
unsafeBitCast($0, to: (@convention(c) () -> UnsafeMutableRawPointer).self)
} → nil
✘ Test "v0 experimental entry point with a large number of filter arguments" recorded an issue at ABIEntryPointTests.swift:57:11: Expectation failed:
symbol(in: testingLibrary, named: "swt_copyABIEntryPoint_v0").map {
unsafeBitCast($0, to: (@convention(c) () -> UnsafeMutableRawPointer).self)
} → nil

I also tried enabling the additional PROCESS_SPAWNING tests which are currently disabled on iOS and Android, which required a few source tweaks and passed its one test, and the new EXIT_TESTS, which had several test failures on Android. I intend to clean up and get both of those working on Android then submit pulls to enable that functionality on Android too, at least for the native Termux app on Android which functions more like a regular Unix environment.

[grynspan]

✘ Test v0_experimental() recorded an issue at ABIEntryPointTests.swift:57:11: Expectation failed:

These tests shouldn't be running at all on Android, and only need to run/pass on Apple platforms for compatibility with Xcode 16.0. SWT_NO_SNAPSHOT_TYPES should be set on Android to disable them and the code they test.

Just checked the Package.swift manifest and we're not setting it for Android explicitly, so I'll fix that in a separate PR.

I also tried enabling the additional PROCESS_SPAWNING tests which are currently disabled on iOS and Android, which required a few source tweaks and passed its one test, and the new EXIT_TESTS, which had several test failures on Android. I intend to clean up and get both of those working on Android then submit pulls to enable that functionality on Android too, at least for the native Termux app on Android which functions more like a regular Unix environment.

It'd be cool to get exit tests working on Android; we'll want to make sure they work "out of the box", or as close to it as possible. If they need lots of special configuration to work, or if they may fail spuriously depending on a developer's setup, I would hesitate to enable them. If that's the case, let's maybe find time in the next Platform Steering Group meeting to discuss options?

[finagolfin]

SWT_NO_SNAPSHOT_TYPES should be set on Android to disable them and the code they test.
Just checked the Package.swift manifest and we're not setting it for Android explicitly, so I'll fix that in a separate PR.

The rest of that code appears to run fine on Android, so maybe only those two tests should be turned off on Android.

If they need lots of special configuration to work, or if they may fail spuriously depending on a developer's setup, I would hesitate to enable them. If that's the case, let's maybe find time in the next Platform Steering Group meeting to discuss options?

I'm not sure, as I simply tried them, saw failing tests, then turned them off. 😉 I'm not in the PSG, but when I try to get those working, I'll let you know what I find.

[grynspan]

SWT_NO_SNAPSHOT_TYPES should be set on Android to disable them and the code they test.
Just checked the Package.swift manifest and we're not setting it for Android explicitly, so I'll fix that in a separate PR.

The rest of that code appears to run fine on Android, so maybe only those two tests should be turned off on Android.

The rest of the code should build and run without issue, it's just dead code on Android (it only exists to support Xcode 16.) Opened #994.