Create Sdk.props in AOT compilers with a template

[directhex]

Fixes #53653

Example:

sudo cat Sdk/Sdk.props
<Project>
  <ItemGroup>
    <MonoAotCrossCompilerPath Include="$(MSBuildThisFileDirectory)..\tools\mono-aot-cross" RuntimeIdentifier="iossimulator-arm64" />
  </ItemGroup>
</Project>

[directhex]

runtime-staging is green, dunno why it's stuck on yellow

[radical]

We should replace the uses of $(MonoAotCrossCompilerPath) in dotnet/runtime with the item, to be consistent.

And can we rename it to something that would suggest that it's not a property? I can't think of a good name though - maybe @(MonoAotCrossCompiler) ? :/

[directhex]

@radical where are we actually consuming the property from an Sdk.props, within the runtime repo? I've got a rune to select the right path from the items (@(MonoAotCrossCompiler->WithMetadataValue('RuntimeIdentifier','browser-wasm'))), but for the most part it seems we're writing the property ourselves, in multiple places (eng/testing/tests.targets, src/libraries/sendtohelixhelp.proj, src/mono/Directory.Build.props, src/mono/wasm/build/WasmApp.LocalBuild.props)

[radical]

where are we actually consuming the property from an Sdk.props, within the runtime repo?

we don't.

but for the most part it seems we're writing the property ourselves, in multiple places

Yep! Um so, in the repo we use compiler from the artifacts directly, so Sdk.props wouldn't come into play (till we get some local workload based testing). I'm suggesting to follow the same item+metadata thing, in all these places where we are writing+using it ad-hoc.

[directhex]

@radical ok, understood, wanted to make sure I was on the same page.

That sounds like an exciting and awesome job for TomorrowMan.

[steveisok]

We should replace the uses of $(MonoAotCrossCompilerPath) in dotnet/runtime with the item, to be consistent.

And can we rename it to something that would suggest that it's not a property? I can't think of a good name though - maybe @(MonoAotCrossCompiler) ? :/

I think that can be done in a follow up PR.

@directhex can you run an official build to make sure we're ok there?

[radical]

You will at least need to update the wasm targets in src/mono/wasm/build, or that will break building with workloads. And try this out as a workload pack.

[steveisok]

You will at least need to update the wasm targets in src/mono/wasm/build, or that will break building with workloads. And try this out as a workload pack.

You're right. Since iOS and Android are the ones that have > 1 AOT compiller, can we isolate this change to them and follow up with the other changes (wasm/workload and intree prop/item refactoring)?

[directhex]

@steveisok I think it should all go into the one PR. It'll just be confusing if it's not unified.

[directhex]

@radical any further concerns?

[lambdageek]

Attn: @rolfbjarne iOS workloads will need to change uses of $(MonoAotCrossCompilerPath) to selecting from the @(MonoAotCrossCompiler) item:

https://github.com/xamarin/xamarin-macios/blob/8ca5d5ea5c062093220cf289f1992edbcb45dcec/dotnet/targets/Xamarin.Shared.Sdk.targets#L463