-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Adding HelloiOS sample for NativeAOT #82249
Conversation
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsThis PR introduces necessary changes to build and run a sample application with NativeAOT on iOS-like platforms. What is included
Takeaways
Fixes #80911
|
Tagging subscribers to 'os-ios': @steveisok, @akoeplinger Issue DetailsThis PR introduces necessary changes to build and run a sample application with NativeAOT on iOS-like platforms. What is included
Takeaways
Fixes #80911
|
63483f2
to
18cd129
Compare
|
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
370033d
to
c09b462
Compare
@@ -0,0 +1,55 @@ | |||
# NativeAOT iOS sample app |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it under mono folder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree the location is not ideal as I wrote in the description, I wanted to avoid interrupting the repo tree and think that until we have more complete support with NativeAOT it might stay like this, as these samples are generally used as PoC. Later, once we have more complete NativeAOT on iOS support, we should move the sample into a tests directory where it should become a functional test. Nevertheless, I am open for suggestions where to place the application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW NativeAOT keeps samples here: https://github.com/dotnet/samples/tree/main/core/nativeaot
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's also https://github.com/dotnet/runtime/tree/main/src/samples which may be better than the mono
location. I assume the desire is to keep it in the same repository to allow quick iteration of AppleAppBuilder changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MichalStrehovsky what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion. If the sample is not building/testing, it will go stale and stop working quickly. This sample is digging into too many unstable internals to be placed in the dotnet/samples repo.
I don't know about the src/samples directory. It looks like it's something we imported from runtimelab. It's unclear if intentionally; can't find any docs for what it is. If I try to dotnet build
the project in it, it doesn't seem to build.
It's not clear to me who the target audience for the sample is. I don't have an opinion on where it should be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear to me who the target audience for the sample is.
The target audience, for now, are developers contributing to NativeAOT on iOS work and the sample serves as a verification method to locally test a change (or series of changes).
On the other hand, the sample is also a "proof" that with the current state of dotnet/runtime main, one can build an iOS-like application targeting different platforms with NativeAOT.
Once we have runtime packages ready, they will be referenced instead of referencing internals explicitly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I was trying to say is that if this is not building/running, it will go stale and might as well live in a personal repo of one of the devs. It will likely get regularly broken now or in the future. If it's building and running, it would qualify as a test and would go to src/tests. I'm not firm on any of this but I was asked for an opinion :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand, and I am grateful for your input! :)
I was just describing the reasoning behind it.
Another thing I forgot the mention, is that the Mono sample, living in: https://github.com/dotnet/runtime/tree/main/src/mono/sample/iOS, is built regularly in size/performance regression tracking, so was thinking that in the future the same approach can be used for NativeAOT as well. This would prevent the sample to go stale.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had very similar discussion when src/mono/sample was added initially. The problem is that we have overloaded meaning of samples.
- Product samples that customers can copy&paste and they just work. These samples live in dotnet/samples repo. Samples under src/mono/sample or src/samples are not that. They depend on the rest of the repo, internal details and they are not generally something we would like to see replicated in uncontrolled way.
- Basic apps that people working on the dotnet/runtime repo find convenient for ad-hoc testing and that are sometimes used for other purposes, like perf testing. They are simple end-to-end tests more than anything else. We use multiple conventions for these projects.
src\coreclr\tools\aot\ILCompiler\repro
is another example of this kind of convenience project. I think it is confusing that we call these samples.
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
@ivanpovazan @akoeplinger should there be a nativeaot pipeline to avoid running the kitchen sink? |
Yes, maybe not required at the moment, but would be good to have some way of verifying the changes in the future (I suppose maccatalyst as a test platform?). The reason I ran |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor suggestions, LGTM.
|
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-ioslike |
Azure Pipelines successfully started running 1 pipeline(s). |
Failures are unrelated. |
This PR introduces necessary changes to build and run a sample application with NativeAOT on iOS-like platforms.
The application is intended to be used by developers who work on enabling NativeAOT on iOS-like platforms and can serve as PoC.
What is included
Takeaways
InvariantGlobalization
as the libraries are still not being built for NativeAOT on iOS Fix NativeAOT ICU build integration for Apple mobile platforms #82389Contributes to: #80911