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 {,t}{a6,arm64}ios machine types #864

Merged
merged 5 commits into from
Sep 9, 2024
Merged

add {,t}{a6,arm64}ios machine types #864

merged 5 commits into from
Sep 9, 2024

Conversation

Bogdanp
Copy link
Contributor

@Bogdanp Bogdanp commented Aug 19, 2024

In support of racket/racket#5057

@Bogdanp Bogdanp changed the title add {,t}{a,arm64}ios machine types add {,t}{a,arm}64ios machine types Aug 19, 2024
@Bogdanp Bogdanp changed the title add {,t}{a,arm}64ios machine types add {,t}{a6,arm64}ios machine types Aug 19, 2024
@jltaylor-us
Copy link
Contributor

Why does Chez Scheme need to distinguish between OSX and iOS? I don't see any code in this PR that treats them any differently.

@Bogdanp
Copy link
Contributor Author

Bogdanp commented Aug 22, 2024

@jltaylor-us the intent of the change is to let user code distinguish between a Chez Scheme build for macOS and one for iOS, to make it possible for the same code to support both platforms in the places that they differ. For example, from the Racket PR I linked:

@jltaylor-us
Copy link
Contributor

Are the object files produced by compile-file, etc, binary compatible between macOS, iOS, and iPadOS?

@Bogdanp
Copy link
Contributor Author

Bogdanp commented Aug 22, 2024

As far as I understand, yes, apart from the machine type flag[1]. But, I think so would the objects produced by the tarm64fb and tarm64nb builds of Chez, yet we still have those machine types so that we can distinguish between FreeBSD and NetBSD builds (but maybe I'm missing something).

[1]: i.e. without this change, a tarm64osx build for macOS and a tarm64osx build for iOS would produce the same object files. With, this change, a tarm64ios build will have a different machine type in the output than a tarm64osx build, though the rest of the output will be the same.

@jltaylor-us
Copy link
Contributor

hmm... I'm not sure why the different BSDs have different machine types either. (but maybe because they are distinct kernels, whereas iOS and MacOS still share the same XNU kernel, I think?)
In any case, if iOS is going to have its own machine types then they need to be documented in the release notes, and configure needs to be updated to detect when it should produce those machine types. Unless you can't actually build them with the normal build process after configure, in which case there should be some instructions somewhere (presumably BUILDING) on how to build those machine types.

@Bogdanp
Copy link
Contributor Author

Bogdanp commented Aug 25, 2024

@jltaylor-us I've added some docs. I wasn't sure how much detail to go into in the release notes re. iOS support, so let me know if you think more is needed.

Building for iOS requires cross-compilation so I've opted to just update BUILDING instead of changing configure.

@jltaylor-us
Copy link
Contributor

Seems ok to me. I'm not sure I understand the practical applications of iOS support if it only works when attached to a debugger, but I assume someone has a use for it or you wouldn't be bothering with this PR.

Let's give it a few days to see if any of the other maintainers have anything to add.

@Bogdanp
Copy link
Contributor Author

Bogdanp commented Aug 25, 2024

Just added a small clarification that the new notes apply to the native backend (as opposed to PB). Re. use cases: I have an iOS app on the AppStore built with Racket-on-Chez, and I'm now working on a second. The released versions use the PB backend and I use it in development as well, but I do test against the native backend every now and then. My hope is they'll eventually lift the restriction.

@Bogdanp
Copy link
Contributor Author

Bogdanp commented Sep 9, 2024

Looks like there haven't been any new comments in the last couple of weeks so maybe it's time to merge this?

@jltaylor-us jltaylor-us merged commit f01e22d into cisco:main Sep 9, 2024
15 checks passed
@jltaylor-us
Copy link
Contributor

Thanks for this contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants