Set CMP0157 to OLD for Android

[Steelskin]

There is no early swift-driver build for the Windows toolchain. As a result, swift-collections fails to build properly when CMP0157 is set to NEW due to object files not being generated.

This sets CMP0157 to OLD when targetting Android until the early swift-driver is available on Windows.

[weliveindetail]

Facing this issue as well. This sounds like a good compromise. Is it happening on other platforms too? Otherwise we might want to add CMAKE_HOST_SYSTEM_NAME STREQUAL Windows to the condition.

[Steelskin]

Facing this issue as well. This sounds like a good compromise. Is it happening on other platforms too? Otherwise we might want to add CMAKE_HOST_SYSTEM_NAME STREQUAL Windows to the condition.

It works fine when building for Windows, but the Android build does not take kindly to not having the early swift-driver.

[weliveindetail]

What I meant was: The issue doesn't reproduce when running Android build on Linux right?

[Steelskin]

What I meant was: The issue doesn't reproduce when running Android build on Linux right?

Ah sorry, I have no idea. I am assuming there is no early swift-driver on Linux either since that requires a static build.

[finagolfin]

I am not that familiar with this CMake policy, which appears to enable using the new CMAKE_Swift_COMPILATION_MODE flag, looks like it was just added with the Foundation rewrite merged last summer. Looking at the CMake config below it appears that configuring that new CMAKE_Swift_COMPILATION_MODE flag here is disabled on Windows hosts, so I'm not sure how it is affecting you.

Is it that CMake sets CMAKE_Swift_COMPILATION_MODE to some default value anyway if CMP0157 is enabled? If so, you'll want to narrow this pull to if(POLICY CMP0157 AND CMAKE_HOST_SYSTEM_NAME STREQUAL Windows AND CMAKE_SYSTEM_NAME STREQUAL Android), as Stefan says.

I am assuming there is no early swift-driver on Linux either since that requires a static build.

No, the linux CI builds and uses the early swift-driver, as you can see on any recent CI run (search for earlyswiftdriver), and you can always pass in a prebuilt linux toolchain that includes the new swift-driver to build this repo.

My Android CI builds this repo just fine from a linux host using such an official prebuilt linux toolchain.

Btw, what is up with @hyp, will he be back?

[Steelskin]

I am not that familiar with this CMake policy, which appears to enable using the new CMAKE_Swift_COMPILATION_MODE flag, looks like it was just added with the Foundation rewrite merged last summer. Looking at the CMake config below it appears that configuring that new CMAKE_Swift_COMPILATION_MODE flag here is disabled on Windows hosts, so I'm not sure how it is affecting you.

When CMP0157 is set to OLD, the swiftmodule and static library are built in a single ninja step. The step also expects that the object files are built in the process but they are not consumed by any other target. When CMP0157 is set to NEW, the generated ninja file includes 2 targets: one to build the swiftmodule + object files and one to build the static library.
The problem occurs when swift-driver is not present (as is the case on Windows when building the toolchain). When targeting Android, the object files are not built, resulting in the target to build the static library failing. As a workaround, we are using an older CMake version in GHA swift-build.

Is it that CMake sets CMAKE_Swift_COMPILATION_MODE to some default value anyway if CMP0157 is enabled? If so, you'll want to narrow this pull to if(POLICY CMP0157 AND CMAKE_HOST_SYSTEM_NAME STREQUAL Windows AND CMAKE_SYSTEM_NAME STREQUAL Android), as Stefan says.

Thanks, I did that.

Btw, what is up with @hyp, will he be back?

He has gone to pursue a different field. He might pop up every once in a while, though :)

[finagolfin]

@swift-ci please test

[finagolfin]

He has gone to pursue a different field.

OK, only reason I asked is because Tony and I were still pinging him on recent pulls, we'll stop doing that. 😉

[weliveindetail]

The Windows build succeeded: https://ci-external.swift.org/job/swift-corelibs-foundation-PR-windows/618/ Any ideas why results were not reported?

[weliveindetail]

The bot checked out the correct commit 4af0f8c, but then it reported the result for the outdated commit:

Adding one-line test results to commit status...
Setting status of a563acec95f721223859b2e704843f6ca78611e7 to SUCCESS with url https://ci-external.swift.org/job/swift-corelibs-foundation-PR-windows/618/ and message [...]

a563ace did actually get accepted 🤷‍♂️

[weliveindetail]

Let's try that again.

@swift-ci please test Windows