[release/7.0] Disable NativeAOT subset for source-build.

[crummel]

Follow-up to #71853.
Tracking issue in source-build is dotnet/source-build#2885.
If merged obsoletes #74505.

The source-build understanding is:

• We are currently using the Microsoft-built NativeAOT bits in the final SDK when an end-user wants to publish a NativeAOT project. These aren't shipped with the SDK but are pulled down when an end-user wants to publish a NativeAOT project.
• There are more extensive changes necessary to NativeAOT in general if it will ever be supported as a source-built component due to the difference in how source-build uses primarily RID-specific assets vs the portable assets generally used in the Microsoft-build (from issues NativeAOT doesn't work with Linux non-portable build #66859 and Support building sdks that can build self-contained / ReadyToRun / NativeAOT applications without using pre-builts from nuget.org source-build#1215).
• Our partners view this as an acceptable trade-off at least for the time being.
• We would like to eliminate the remaining patches and churn/risk of building llvm-project.
• We would like to continue building, for example, crossgen2 and other native-related projects.

I would like to make the minimal change necessary to disable the dependency on llvm-project in runtime without breaking any end-user functionality and this subset seems like it should fit that bill - please let me know if I'm wrong.

[ghost]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[crummel]

cc @tmds@omajid@jkotas@dsplaisted

[ghost]

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Follow-up to #71853.
Tracking issue in source-build is dotnet/source-build#2885.
If merged obsoletes #74505.

The source-build understanding is:

• We are currently using the Microsoft-built NativeAOT bits in the final SDK when an end-user wants to publish a NativeAOT project. These aren't shipped with the SDK but are pulled down when an end-user wants to publish a NativeAOT project.
• There are more extensive changes necessary to NativeAOT in general if it will ever be supported as a source-built component due to the difference in how source-build uses primarily RID-specific assets vs the portable assets generally used in the Microsoft-build (from issues NativeAOT doesn't work with Linux non-portable build #66859 and Support building sdks that can build self-contained / ReadyToRun / NativeAOT applications without using pre-builts from nuget.org source-build#1215).
• Our partners view this as an acceptable trade-off at least for the time being.
• We would like to eliminate the remaining patches and churn/risk of building llvm-project.
• We would like to continue building, for example, crossgen2 and other native-related projects.

I would like to make the minimal change necessary to disable the dependency on llvm-project in runtime without breaking any end-user functionality and this subset seems like it should fit that bill - please let me know if I'm wrong.

Author:	crummel
Assignees:	crummel
Labels:	area-Infrastructure-coreclr
Milestone:	-

[jkotas]

We are currently using the Microsoft-built NativeAOT bits in the final SDK when an end-user wants to publish a NativeAOT project. These aren't shipped with the SDK but are pulled down when an end-user wants to publish a NativeAOT project.

This is true except for the Microsoft.DotNet.ILCompiler package with build integration that is bundled into the SDK (look for Sdks\Microsoft.DotNet.ILCompiler). The way things are setup today this package has to bundled into the SDK to allow pulling down the NativeAOT compiler.

Is the Microsoft.DotNet.ILCompiler package still getting built with the right content with this change?

[jkotas]

make the minimal change necessary to disable the dependency on llvm-project

This dependency is in clr.tools subset here: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/aot/ILCompiler/ILCompiler.props#L40-L47. How is disabling clr.nativeaotlibs for source build suppressing this dependency? Have you validated that this change is actually suppressing this dependency?

[crummel]

You're right, I need to look at this more. I'll get this updated. Thanks!

[crummel]

After discussion with @LakshanF and the source-build team, we will need the ObjWriter bits eventually in 7.0 even if not for NativeAOT, so I'll close this PR.

[jkotas]

@crummel Could you please explain the reasoning more? As far as I know, we should not need ObjWriter in 7.0. I would like to understand why you believe that it is not the case.

[LakshanF]

That was a misunderstanding, @crummel and I chatted again and understood we don't need ObjWriter in 7.0

[crummel]

I've updated the PR to only remove the ObjWriter bits. I've verified runtime builds in the source-build context with this change and no longer restores the ObjWriter package. I have a build going to test that everything works in the rest of the SDK and will verify NativeAOT publishing from the end-user's perspective after that's done. Does this look like a better change @LakshanF and @jkotas ? Any other testing that seems advisable?

[jkotas]

Yes, this looks better.

[crummel]

Hi @jkotas, I kicked the CI and everything is green now. I don't have merge permissions so this is good to go whenever you're ready.

[carlossanlop]

CI is green. Removed the no-merge label since it has been signed-off by @jkotas. This is an infra-only change so no Tactics approval needed.

Ready to merge.

[crummel]

Thanks!

[MichaelSimons]

@crummel - did this get backported to main?

[crummel]

I believe we worked out with @LakshanF and @jkotas that additional pieces of runtime including crossgen2 (which source-build requires) would need ObjWriter/llvm in 8.0 so we didn't want to backport this since we'll have the bits anyway. Unless I misunderstood the 8.0 plans, correct me if I'm wrong please Lakshan and Jan.

[jkotas]

Yes, we will need that for the eventual unified VMR build in .NET 8/9.

This is very simple change to port and undo later. If we want to have a source build working in .NET 8 sooner rather than later, it may be worth it to port it.