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

Adding HelloiOS sample for NativeAOT #82249

Merged
merged 10 commits into from
Feb 24, 2023
Prev Previous commit
Markdown cleanup
ivanpovazan committed Feb 24, 2023

Verified

This commit was signed with the committer’s verified signature.
chuckha Chuck Ha
commit d69ba2ef9f6619e9b33aa3cb1d849dc83a329a1d
6 changes: 3 additions & 3 deletions src/mono/sample/iOS-NativeAOT/README.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# NativeAOT iOS sample app
Copy link
Contributor

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?

Copy link
Member Author

@ivanpovazan ivanpovazan Feb 20, 2023

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@filipnavara filipnavara Feb 20, 2023

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

@ivanpovazan ivanpovazan Feb 21, 2023

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.

Copy link
Member

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 :)

Copy link
Member Author

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.

Copy link
Member

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.


## Description
## Description

This sample application is intended to be used by developers who work on enabling NativeAOT on iOS-like platforms and can serve as PoC for verifying support for the following systems:
- ios
@@ -16,7 +16,7 @@ The sample shares the source code with the Mono sample specified at: `../iOS/Pro
The application is **_currently_** relying on the following:
1. Internal dependencies - locally building the internals is required as runtime and tools nuget packages are still not being produced
2. Invariant globalization - `System.Globalization.Native` is currently not being built as part of NativeAOT framework for iOS-like platforms
3. No publish targets - the SDK and MSBuild integration is still not complete
3. No publish targets - the SDK and MSBuild integration is still not complete

## How to build and test

@@ -64,7 +64,7 @@ export DevTeamProvisioning=A1B2C3D4E5; make hello-app TARGET_OS=ios DEPLOY_AND_R
```
Assuming `A1B2C3D4E5` is a valid team ID.

#### Oneliner
#### One-liner

On a clean dotnet/runtime checkout, from this directory, run: