-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[NativeAOT] Clean up AOT Publishing #72415
Comments
@LakshanF could you milestone the issue and remove untriaged? It shows up in queries. |
Incorporating @sbomer suggestions below The native AOT application publishing experience is outlined below for supported scenarios for PublishAot property and when an explicit package reference to Publishing a native AOT application requires 2 external packages, The options below take different paths to acquire the packages.
These scenarios impose the following requirements
These requirements are currently implemented in the following way
Runtime repo impact
SDK repo impact
|
I think we should simplify the third scenario to behave either identically to the second (as if PublishAot were set to true), or to not do an AOT publish at all. Since the OOB package scenario is already in use, I would probably make it behave like PublishAot is true.
I think that setting PublishAot to false should prevent AOT publish, turn off the AOT analyzer, etc, even if there is a package reference. |
The PR is getting reverted. |
@LakshanF you still had some concerns around this in the meeting. Should we keep open or it's good to close? |
I would like to keep this open for a little longer. I need to clean up the tests in SDK and that requires the runtime changes to flow there. Will do that soon. |
Validated the test in the rc1 branch, including cross-target scenario without the explicit packages in the project. However, the test will only be updated on the main branch and not on the RC1 branch due to the high bar for changes in the RC1 |
Given that building a native AOT application is supported only via the SDK (with the option to get the latest ILCompiler* packs via an explicit reference), the publish path with properties, items, tasks, and targets etc., should be cleaned up. The history of this code has been with specific goals that have changed over time,
PublishAot
with backward compatibility support (for a short period) for the explicit package reference without the SDK pathPublishAot
. Explicit package reference takes precedence when one exists (for example, to pick up bug fixes in the package earlier)It should be easy to follow the publishing logic which currently is a little convoluted.
Specifically,
The text was updated successfully, but these errors were encountered: