Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add macCatalyst to the PlatformChecks #524

Merged
merged 2 commits into from
Feb 13, 2024

Conversation

lennartkerkvliet
Copy link
Contributor

Motivation

When attempting to compile the Swift OpenAPI Generator on MacCatalyst, code that compiles on iOS will not compile as it will fail on the PlatformChecks.

Modifications

Added an extra condition in PlatformChecks to allow running on MacCatalyst.

Result

fixes #523

Test Plan

I've tried to familiarize myself with the project, but could not come up with a good way to add a test for running the tool on MacCatalyst. In my manual testing giving the instructions in the issue, it now works as expected.

@simonjbeaumont
Copy link
Collaborator

When attempting to compile the Swift OpenAPI Generator on MacCatalyst...

When compiling an iOS app, you run the generator on your macOS developer environment (usually by using the Swift package plugin), but you only link the runtime library to your app. The platform checks here are to stop you linking the generator itself in applications by mistake.

Are you trying to compile for MacCatalyst or on MacCatalyst?

@lennartkerkvliet
Copy link
Contributor Author

lennartkerkvliet commented Feb 6, 2024

@simonjbeaumont Good question! I wrote about this in the issue a bit more

I suspect that it has to do with the behaviour of MacCatalyst. When compiling the app normally targetEnvironment(macCatalyst) will be true while os(macOS) will be false which is already confusing by itself but with good reason. Perhaps the build tool plug-in is ran in a similar environment?

So importantly, no, I did not link to the generator. With the changes PlatformChecks, the generator will also not be embedded in the final build. I wouldn't be surprised if it's some sort of oversight in building for Catalyst. If you'd like to try it out for yourself, just take any project with the OpenAPI generator for iOS and add MacCatalyst as a supported destination. I would also be glad to provide a sample project, although it's quite straightforward to reproduce.

@lennartkerkvliet
Copy link
Contributor Author

Here's an Xcode project reproducing the issue. The same configuration compiles on iOS while failing to compile on Catalyst.
OpenAPI-Catalyst.zip

@simonjbeaumont
Copy link
Collaborator

Thanks for the response and for the reproducer. I can see locally with a dummy package that, when compiling the application code:

  1. When compiling for destination "My Mac", I see os(macOS) is true and targetEnvironment(macCatalyst) is false.
  2. When compiling for destination "My Mac (Mac Catalyst), I see os(iOS) is true and targetEnvironment(macCatalyst) is true.
  3. When compiling for a simulator, e.g. "iPhone 15", I see os(iOS) is true and targetEnvironment(simulator) is true.

This is all expected in the code for the application. What's unexpected is the compiler conditions that are used to build the package plugin:

  • In scenario (3), things work fine because when compiling the plugin it uses os(macOS).
  • In scenario (2), things do not work because when compiling the plugin it uses os(iOS).

I think this is a bug in the build system. For now, we can workaround it with this patch—although I've suggested an edit to document it clearer. Would you mind filing an issue using Feedback Assistant and let us know the issue number?

@lennartkerkvliet
Copy link
Contributor Author

@simonjbeaumont Here's the feedback identifier: FB13589581

@simonjbeaumont
Copy link
Collaborator

@swift-server-bot test this please

@simonjbeaumont simonjbeaumont enabled auto-merge (squash) February 13, 2024 10:59
@simonjbeaumont
Copy link
Collaborator

Nightly failure is a compiler crash:

error: compile command failed due to signal 6 (use -v to see invocation)
SIL verification failed: keypath value type should match value type of keypath pattern
  any CodingKey
  URICoderCodingKey
Verifying instruction:
->   %8 = keypath $KeyPath<URIValueFromNodeDecoder.CodingStackEntry, any CodingKey>, (root $URIValueFromNodeDecoder.CodingStackEntry; stored_property #URIValueFromNodeDecoder.CodingStackEntry.key : $URICoderCodingKey) // user: %9
     %9 = move_value [lexical] [var_decl] %8 : $KeyPath<URIValueFromNodeDecoder.CodingStackEntry, any CodingKey> // users: %15, %11
In function:
// URIValueFromNodeDecoder.codingPath.getter

Merging over this.

@simonjbeaumont simonjbeaumont merged commit 7992d77 into apple:main Feb 13, 2024
8 of 9 checks passed
@simonjbeaumont
Copy link
Collaborator

Thanks @lennartkerkvliet!

@simonjbeaumont simonjbeaumont added the 🔨 semver/patch No public API change. label Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔨 semver/patch No public API change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PlatformChecks emits error when compiling for MacCatalyst
2 participants