Allow building libs against NativeAOT CoreLib #62945
Conversation
To make sure ApiCompat tooling runs at least in some legs, compile libs against NativeAOT corelib if we're building CLR, but not building the JIT flavor of the runtime. The baselining is necessary because the reflection stack of NativeAOT doesn't live in CoreLib. The CannotRemoveBaseTypeOrInteface baselining will go away once we fix dotnet#62944. It's one of the "overall goodness" things we can take out of NativeAOT and put it into all runtimes.
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsTo make sure ApiCompat tooling for NativeAOT's CoreLib runs at least in some legs, compile libs against NativeAOT CoreLib if we're building CLR, but not building the JIT flavor of the runtime. The baselining is necessary because the reflection stack of NativeAOT doesn't live in CoreLib. The CannotRemoveBaseTypeOrInteface baselining will go away once we fix #62944. It's one of the "overall goodness" things we can take out of NativeAOT and put it into all runtimes.
|
ghost
added this to In Progress
in 
|
Has there been any thought to implementing this with a new value for RuntimeFlavor instead? That way we can plumb through NativeAOT-specific paths in our infra using similar mechanisms to how we switch between CoreCLR and Mono. |
I'm not sure RuntimeFlavor is the right axis - we probably want to take the CoreCLR paths most of the time - it's more like a RuntimeVariant - but only Mono defines RuntimeVariants right now. On CoreCLR we have R2R/non-R2R axis for testing that doesn't affect product build. If we need more of these special casings we can take a step back, but this might be the only special casing we need. It's possible that at some point around .NET 8 we'll have a single universal CoreLib that works for both CoreCLR-JIT and CoreCLR-NativeAOT. We already started unification of internal details in that direction (e.g. we started renaming NativeAOT's |
To make sure ApiCompat tooling for NativeAOT's CoreLib runs at least in some legs, compile libs against NativeAOT CoreLib if we're building CLR, but not building the JIT flavor of the runtime.
The baselining is necessary because the reflection stack of NativeAOT doesn't live in CoreLib.
The CannotRemoveBaseTypeOrInteface baselining will go away once #62944 gets fixed. It's one of the "overall goodness" things we can take out of NativeAOT and put it into all runtimes.