Add iOS build configurations

[akoeplinger]

This adds support for iOS using the Mono runtime to the build system.

I'm only adding the build integration right now, CI support will be done separately.

[filipnavara]

I'd expect iOS to set CLR_CMAKE_TARGET_DARWIN too. Not sure whether it would make the rest of the diff with if conditions smaller or larger though.

[am11]

Yes please, at least on cmake side, we are consistent with Darwin naming. It's only the code and RIDs where the (obsolete) osx name is used. 😁

[akoeplinger]

This was a conscious decision because CLR_CMAKE_TARGET_DARWIN really means macOS in the rest of the build scripts. We could rename it to CLR_CMAKE_TARGET_OSX?

[akoeplinger]

I'll do the renaming in a follow-up PR.

[bartonjs]

What's the minimum target iOS? 9 stopped getting patches 3 years ago (modulo one patch for GPS rollover last year). Even 10 looks to be out of support other than the GPS fix.

[akoeplinger]

The minimum target that Xamarin supports today is iOS 7 for devices and iOS 8 for the simulator so I replicated that here. We're discussing with PM but it looks like we won't be able to meaningfully bump the minimum version, definitely not to 10.

[marek-safar]

@ViktorHofer any objections?

[ViktorHofer]

I hadn't yet that time to review the PR. Please wait until #33242 is in (should be in ~1 hour) on which I was working the last few days to avoid conflicts. I will now review the PR.

[akoeplinger]

Sure. I'll need to push another merge anyway due to conflicts so I can wait for that PR to land.

[ViktorHofer]

@ViktorHofer any objections?

a lot's going on today. I just requested review from dotnet/runtime-infrastructure as well. I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable. Please don't merge the change yet before me and the infra teams has taken a closer look. Thanks for your understanding.

[akoeplinger]

I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable.

@ViktorHofer let me know if what I proposed in #33292 (comment) makes more sense, thanks.

[directhex]

I'm branching off this to try and get the AzDO YAML going. Will rebase as and when.

[am11]

Could we instead:

Suggested change

	if(NOT CLR_CMAKE_CONFIGURE_PLATFORM_INCLUDED)
	message(FATAL_ERROR"configuretools.cmake needs to be included after configureplatforms.cmake")
	endif()
	include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)

and remove three occurrences of include(${CLR_ENG_NATIVE_DIR}/configureplatform.cmake) under :/src/? This way we would only use configuretools.cmake as an entrypoint cmake for eng/native (and rest of the files will become internal detail, which however may get refactored in the future).

[am11]

or perhaps for all call sites, we can add an explicit :/eng/native/entrypoint.cmake enlisting:

include(${CMAKE_CURRENT_LIST_DIR}/functions.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configuretools.cmake)

[akoeplinger]

Yes I think this makes sense. I'd prefer if we do it in a separate PR though :)

[am11]

I have addressed it as part of Android fixes #32800.

[steveisok]

@dotnet/runtime-infrastructure Can one or more of you give this a review? I'd like to have this merged today if possible.

[safern]

Should we error if SubsetCategory is not empty and contains either installer or coreclr when TargetOS is iOS?

[akoeplinger]

I feel like if you manually override subset category that way you deserve to get the failures :)

[safern]

I get that, but it is good to help developers get readable failures? Sometimes because of the lack of those validations we get a lot of questions, why this doesn't work, why am I getting this error, etc? We already have a target that does validation for the subset categories, if I remember correctly.

[ViktorHofer]

I think it's ok to set RuntimeFlavor based on the passed in SubsetCategory but I don't think that SubsetCategory should be inferred from TargetOS. The SubsetCategory can also contain values like mono, or mono-coreclr-libraries-installer therefore I think it's necessary to be intentional here and require the category to be passed in.

[akoeplinger]

@ViktorHofer why not? coreclr or installer are not valid subset categories when you have TargetOS=iOS so having a default when nothing is set explicitly makes a lot of sense.

[ViktorHofer]

I thought about this more. I'm fine with providing a default value for the subset categories when a configuration is passed in that isn't supported on one of those categories but I would not want to exclude installer which brings me back to my question: Why did you choose mono-libraries and not mono-libraries-installer?

[akoeplinger]

@ViktorHofer installer doesn't make sense at all, there won't be an installer for the iOS bits (nuget only). The default of mono-libraries is everything that we want to build by default.

[akoeplinger]

I can move the change to set DefaultSubsetCategories for TargetOS==iOS instead if that helps making it clearer.

[akoeplinger]

I discussed this with Viktor offline and there was some misunderstanding. installer is not just for building the .deb/.msi/.pkg installers but also does other things like creating runtime packs and ref packs. So we might eventually need it for iOS too.

[akoeplinger]

Regarding the subset validation: Viktor and me took a look and it seems a little more complicated to add than expected. We'll do it in a separate PR.

[safern]

Just curious, why are these set to empty?

[akoeplinger]

Some Apple tools embed certain pieces of metadata differently depending on whether you build against /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk or /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk (the former is a symlink to the latter).

On CI we want to build with the explicit version so we pass in the versions installed on the bots. Locally we don't really care about that and hardcoding the version in the file would just mean you need to change it whenever Xcode is updated, so we rely on the symlink there.

I know MSBuild doesn't require you to declare properties if they're empty but I felt it serves as a good documentation that they're used/available.

[safern]

Makes sense. Thanks for explaining.

[safern]

Other than a few comments/questions, the infra changes LGTM.

[akoeplinger]

dotnet-runtime-perf failures are due to #33082.

[jkotas]

Does this need to be mentioned in https://github.com/dotnet/runtime/blob/master/THIRD-PARTY-NOTICES.TXT ?

[akoeplinger]

Yes, we discussed with @richlander and we'll take care of that.

[ViktorHofer]

discussed various additions to this PR offline with @akoeplinger, like the necessity of the installer subset at a later point for the runtime pack to build. The subset validation as well should be enabled later. LGTM. Thanks!

[akoeplinger]

This adds support for iOS using the Mono runtime to the build system.

I'm only adding the build integration right now, CI support will be done separately.

[filipnavara]

I'd expect iOS to set CLR_CMAKE_TARGET_DARWIN too. Not sure whether it would make the rest of the diff with if conditions smaller or larger though.

[am11]

Yes please, at least on cmake side, we are consistent with Darwin naming. It's only the code and RIDs where the (obsolete) osx name is used. 😁

[akoeplinger]

This was a conscious decision because CLR_CMAKE_TARGET_DARWIN really means macOS in the rest of the build scripts. We could rename it to CLR_CMAKE_TARGET_OSX?

[akoeplinger]

I'll do the renaming in a follow-up PR.

[bartonjs]

What's the minimum target iOS? 9 stopped getting patches 3 years ago (modulo one patch for GPS rollover last year). Even 10 looks to be out of support other than the GPS fix.

[akoeplinger]

The minimum target that Xamarin supports today is iOS 7 for devices and iOS 8 for the simulator so I replicated that here. We're discussing with PM but it looks like we won't be able to meaningfully bump the minimum version, definitely not to 10.

[marek-safar]

@ViktorHofer any objections?

[ViktorHofer]

I hadn't yet that time to review the PR. Please wait until #33242 is in (should be in ~1 hour) on which I was working the last few days to avoid conflicts. I will now review the PR.

[akoeplinger]

Sure. I'll need to push another merge anyway due to conflicts so I can wait for that PR to land.

[ViktorHofer]

@ViktorHofer any objections?

a lot's going on today. I just requested review from dotnet/runtime-infrastructure as well. I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable. Please don't merge the change yet before me and the infra teams has taken a closer look. Thanks for your understanding.

[akoeplinger]

I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable.

@ViktorHofer let me know if what I proposed in #33292 (comment) makes more sense, thanks.

[directhex]

I'm branching off this to try and get the AzDO YAML going. Will rebase as and when.

[am11]

Could we instead:

Suggested change

	if(NOT CLR_CMAKE_CONFIGURE_PLATFORM_INCLUDED)
	message(FATAL_ERROR"configuretools.cmake needs to be included after configureplatforms.cmake")
	endif()
	include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)

and remove three occurrences of include(${CLR_ENG_NATIVE_DIR}/configureplatform.cmake) under :/src/? This way we would only use configuretools.cmake as an entrypoint cmake for eng/native (and rest of the files will become internal detail, which however may get refactored in the future).

[am11]

or perhaps for all call sites, we can add an explicit :/eng/native/entrypoint.cmake enlisting:

include(${CMAKE_CURRENT_LIST_DIR}/functions.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configuretools.cmake)

[akoeplinger]

Yes I think this makes sense. I'd prefer if we do it in a separate PR though :)

[am11]

I have addressed it as part of Android fixes #32800.

[steveisok]

@dotnet/runtime-infrastructure Can one or more of you give this a review? I'd like to have this merged today if possible.

[safern]

Should we error if SubsetCategory is not empty and contains either installer or coreclr when TargetOS is iOS?

[akoeplinger]

I feel like if you manually override subset category that way you deserve to get the failures :)

[safern]

I get that, but it is good to help developers get readable failures? Sometimes because of the lack of those validations we get a lot of questions, why this doesn't work, why am I getting this error, etc? We already have a target that does validation for the subset categories, if I remember correctly.

[ViktorHofer]

I think it's ok to set RuntimeFlavor based on the passed in SubsetCategory but I don't think that SubsetCategory should be inferred from TargetOS. The SubsetCategory can also contain values like mono, or mono-coreclr-libraries-installer therefore I think it's necessary to be intentional here and require the category to be passed in.

[akoeplinger]

@ViktorHofer why not? coreclr or installer are not valid subset categories when you have TargetOS=iOS so having a default when nothing is set explicitly makes a lot of sense.

[ViktorHofer]

I thought about this more. I'm fine with providing a default value for the subset categories when a configuration is passed in that isn't supported on one of those categories but I would not want to exclude installer which brings me back to my question: Why did you choose mono-libraries and not mono-libraries-installer?

[akoeplinger]

@ViktorHofer installer doesn't make sense at all, there won't be an installer for the iOS bits (nuget only). The default of mono-libraries is everything that we want to build by default.

[akoeplinger]

I can move the change to set DefaultSubsetCategories for TargetOS==iOS instead if that helps making it clearer.

[akoeplinger]

I discussed this with Viktor offline and there was some misunderstanding. installer is not just for building the .deb/.msi/.pkg installers but also does other things like creating runtime packs and ref packs. So we might eventually need it for iOS too.

[akoeplinger]

Regarding the subset validation: Viktor and me took a look and it seems a little more complicated to add than expected. We'll do it in a separate PR.

[safern]

Just curious, why are these set to empty?

[akoeplinger]

Some Apple tools embed certain pieces of metadata differently depending on whether you build against /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk or /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk (the former is a symlink to the latter).

On CI we want to build with the explicit version so we pass in the versions installed on the bots. Locally we don't really care about that and hardcoding the version in the file would just mean you need to change it whenever Xcode is updated, so we rely on the symlink there.

I know MSBuild doesn't require you to declare properties if they're empty but I felt it serves as a good documentation that they're used/available.

[safern]

Makes sense. Thanks for explaining.

[safern]

Other than a few comments/questions, the infra changes LGTM.

[akoeplinger]

dotnet-runtime-perf failures are due to #33082.

[jkotas]

Does this need to be mentioned in https://github.com/dotnet/runtime/blob/master/THIRD-PARTY-NOTICES.TXT ?

[akoeplinger]

Yes, we discussed with @richlander and we'll take care of that.

[ViktorHofer]

discussed various additions to this PR offline with @akoeplinger, like the necessity of the installer subset at a later point for the runtime pack to build. The subset validation as well should be enabled later. LGTM. Thanks!

[akoeplinger]

This adds support for iOS using the Mono runtime to the build system.

I'm only adding the build integration right now, CI support will be done separately.

[filipnavara]

I'd expect iOS to set CLR_CMAKE_TARGET_DARWIN too. Not sure whether it would make the rest of the diff with if conditions smaller or larger though.

[am11]

Yes please, at least on cmake side, we are consistent with Darwin naming. It's only the code and RIDs where the (obsolete) osx name is used. 😁

[akoeplinger]

This was a conscious decision because CLR_CMAKE_TARGET_DARWIN really means macOS in the rest of the build scripts. We could rename it to CLR_CMAKE_TARGET_OSX?

[akoeplinger]

I'll do the renaming in a follow-up PR.

[bartonjs]

What's the minimum target iOS? 9 stopped getting patches 3 years ago (modulo one patch for GPS rollover last year). Even 10 looks to be out of support other than the GPS fix.

[akoeplinger]

The minimum target that Xamarin supports today is iOS 7 for devices and iOS 8 for the simulator so I replicated that here. We're discussing with PM but it looks like we won't be able to meaningfully bump the minimum version, definitely not to 10.

[marek-safar]

@ViktorHofer any objections?

[ViktorHofer]

I hadn't yet that time to review the PR. Please wait until #33242 is in (should be in ~1 hour) on which I was working the last few days to avoid conflicts. I will now review the PR.

[akoeplinger]

Sure. I'll need to push another merge anyway due to conflicts so I can wait for that PR to land.

[ViktorHofer]

@ViktorHofer any objections?

a lot's going on today. I just requested review from dotnet/runtime-infrastructure as well. I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable. Please don't merge the change yet before me and the infra teams has taken a closer look. Thanks for your understanding.

[akoeplinger]

I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable.

@ViktorHofer let me know if what I proposed in #33292 (comment) makes more sense, thanks.

[directhex]

I'm branching off this to try and get the AzDO YAML going. Will rebase as and when.

[am11]

Could we instead:

Suggested change

	if(NOT CLR_CMAKE_CONFIGURE_PLATFORM_INCLUDED)
	message(FATAL_ERROR"configuretools.cmake needs to be included after configureplatforms.cmake")
	endif()
	include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)

and remove three occurrences of include(${CLR_ENG_NATIVE_DIR}/configureplatform.cmake) under :/src/? This way we would only use configuretools.cmake as an entrypoint cmake for eng/native (and rest of the files will become internal detail, which however may get refactored in the future).

[am11]

or perhaps for all call sites, we can add an explicit :/eng/native/entrypoint.cmake enlisting:

include(${CMAKE_CURRENT_LIST_DIR}/functions.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configuretools.cmake)

[akoeplinger]

Yes I think this makes sense. I'd prefer if we do it in a separate PR though :)

[am11]

I have addressed it as part of Android fixes #32800.

[steveisok]

@dotnet/runtime-infrastructure Can one or more of you give this a review? I'd like to have this merged today if possible.

[safern]

Should we error if SubsetCategory is not empty and contains either installer or coreclr when TargetOS is iOS?

[akoeplinger]

I feel like if you manually override subset category that way you deserve to get the failures :)

[safern]

I get that, but it is good to help developers get readable failures? Sometimes because of the lack of those validations we get a lot of questions, why this doesn't work, why am I getting this error, etc? We already have a target that does validation for the subset categories, if I remember correctly.

[ViktorHofer]

I think it's ok to set RuntimeFlavor based on the passed in SubsetCategory but I don't think that SubsetCategory should be inferred from TargetOS. The SubsetCategory can also contain values like mono, or mono-coreclr-libraries-installer therefore I think it's necessary to be intentional here and require the category to be passed in.

[akoeplinger]

@ViktorHofer why not? coreclr or installer are not valid subset categories when you have TargetOS=iOS so having a default when nothing is set explicitly makes a lot of sense.

[ViktorHofer]

I thought about this more. I'm fine with providing a default value for the subset categories when a configuration is passed in that isn't supported on one of those categories but I would not want to exclude installer which brings me back to my question: Why did you choose mono-libraries and not mono-libraries-installer?

[akoeplinger]

@ViktorHofer installer doesn't make sense at all, there won't be an installer for the iOS bits (nuget only). The default of mono-libraries is everything that we want to build by default.

[akoeplinger]

I can move the change to set DefaultSubsetCategories for TargetOS==iOS instead if that helps making it clearer.

[akoeplinger]

I discussed this with Viktor offline and there was some misunderstanding. installer is not just for building the .deb/.msi/.pkg installers but also does other things like creating runtime packs and ref packs. So we might eventually need it for iOS too.

[akoeplinger]

Regarding the subset validation: Viktor and me took a look and it seems a little more complicated to add than expected. We'll do it in a separate PR.

[safern]

Just curious, why are these set to empty?

[akoeplinger]

Some Apple tools embed certain pieces of metadata differently depending on whether you build against /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk or /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk (the former is a symlink to the latter).

On CI we want to build with the explicit version so we pass in the versions installed on the bots. Locally we don't really care about that and hardcoding the version in the file would just mean you need to change it whenever Xcode is updated, so we rely on the symlink there.

I know MSBuild doesn't require you to declare properties if they're empty but I felt it serves as a good documentation that they're used/available.

[safern]

Makes sense. Thanks for explaining.

[safern]

Other than a few comments/questions, the infra changes LGTM.

[akoeplinger]

dotnet-runtime-perf failures are due to #33082.

[jkotas]

Does this need to be mentioned in https://github.com/dotnet/runtime/blob/master/THIRD-PARTY-NOTICES.TXT ?

[akoeplinger]

Yes, we discussed with @richlander and we'll take care of that.

[ViktorHofer]

discussed various additions to this PR offline with @akoeplinger, like the necessity of the installer subset at a later point for the runtime pack to build. The subset validation as well should be enabled later. LGTM. Thanks!

[akoeplinger]

This adds support for iOS using the Mono runtime to the build system.

I'm only adding the build integration right now, CI support will be done separately.

[filipnavara]

I'd expect iOS to set CLR_CMAKE_TARGET_DARWIN too. Not sure whether it would make the rest of the diff with if conditions smaller or larger though.

[am11]

Yes please, at least on cmake side, we are consistent with Darwin naming. It's only the code and RIDs where the (obsolete) osx name is used. 😁

[akoeplinger]

This was a conscious decision because CLR_CMAKE_TARGET_DARWIN really means macOS in the rest of the build scripts. We could rename it to CLR_CMAKE_TARGET_OSX?

[akoeplinger]

I'll do the renaming in a follow-up PR.

[bartonjs]

What's the minimum target iOS? 9 stopped getting patches 3 years ago (modulo one patch for GPS rollover last year). Even 10 looks to be out of support other than the GPS fix.

[akoeplinger]

The minimum target that Xamarin supports today is iOS 7 for devices and iOS 8 for the simulator so I replicated that here. We're discussing with PM but it looks like we won't be able to meaningfully bump the minimum version, definitely not to 10.

[marek-safar]

@ViktorHofer any objections?

[ViktorHofer]

I hadn't yet that time to review the PR. Please wait until #33242 is in (should be in ~1 hour) on which I was working the last few days to avoid conflicts. I will now review the PR.

[akoeplinger]

Sure. I'll need to push another merge anyway due to conflicts so I can wait for that PR to land.

[ViktorHofer]

@ViktorHofer any objections?

a lot's going on today. I just requested review from dotnet/runtime-infrastructure as well. I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable. Please don't merge the change yet before me and the infra teams has taken a closer look. Thanks for your understanding.

[akoeplinger]

I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable.

@ViktorHofer let me know if what I proposed in #33292 (comment) makes more sense, thanks.

[directhex]

I'm branching off this to try and get the AzDO YAML going. Will rebase as and when.

[am11]

Could we instead:

Suggested change

	if(NOT CLR_CMAKE_CONFIGURE_PLATFORM_INCLUDED)
	message(FATAL_ERROR"configuretools.cmake needs to be included after configureplatforms.cmake")
	endif()
	include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)

and remove three occurrences of include(${CLR_ENG_NATIVE_DIR}/configureplatform.cmake) under :/src/? This way we would only use configuretools.cmake as an entrypoint cmake for eng/native (and rest of the files will become internal detail, which however may get refactored in the future).

[am11]

or perhaps for all call sites, we can add an explicit :/eng/native/entrypoint.cmake enlisting:

include(${CMAKE_CURRENT_LIST_DIR}/functions.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configuretools.cmake)

[akoeplinger]

Yes I think this makes sense. I'd prefer if we do it in a separate PR though :)

[am11]

I have addressed it as part of Android fixes #32800.

[steveisok]

@dotnet/runtime-infrastructure Can one or more of you give this a review? I'd like to have this merged today if possible.

[safern]

Should we error if SubsetCategory is not empty and contains either installer or coreclr when TargetOS is iOS?

[akoeplinger]

I feel like if you manually override subset category that way you deserve to get the failures :)

[safern]

I get that, but it is good to help developers get readable failures? Sometimes because of the lack of those validations we get a lot of questions, why this doesn't work, why am I getting this error, etc? We already have a target that does validation for the subset categories, if I remember correctly.

[ViktorHofer]

I think it's ok to set RuntimeFlavor based on the passed in SubsetCategory but I don't think that SubsetCategory should be inferred from TargetOS. The SubsetCategory can also contain values like mono, or mono-coreclr-libraries-installer therefore I think it's necessary to be intentional here and require the category to be passed in.

[akoeplinger]

@ViktorHofer why not? coreclr or installer are not valid subset categories when you have TargetOS=iOS so having a default when nothing is set explicitly makes a lot of sense.

[ViktorHofer]

I thought about this more. I'm fine with providing a default value for the subset categories when a configuration is passed in that isn't supported on one of those categories but I would not want to exclude installer which brings me back to my question: Why did you choose mono-libraries and not mono-libraries-installer?

[akoeplinger]

@ViktorHofer installer doesn't make sense at all, there won't be an installer for the iOS bits (nuget only). The default of mono-libraries is everything that we want to build by default.

[akoeplinger]

I can move the change to set DefaultSubsetCategories for TargetOS==iOS instead if that helps making it clearer.

[akoeplinger]

I discussed this with Viktor offline and there was some misunderstanding. installer is not just for building the .deb/.msi/.pkg installers but also does other things like creating runtime packs and ref packs. So we might eventually need it for iOS too.

[akoeplinger]

Regarding the subset validation: Viktor and me took a look and it seems a little more complicated to add than expected. We'll do it in a separate PR.

[safern]

Just curious, why are these set to empty?

[akoeplinger]

Some Apple tools embed certain pieces of metadata differently depending on whether you build against /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk or /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk (the former is a symlink to the latter).

On CI we want to build with the explicit version so we pass in the versions installed on the bots. Locally we don't really care about that and hardcoding the version in the file would just mean you need to change it whenever Xcode is updated, so we rely on the symlink there.

I know MSBuild doesn't require you to declare properties if they're empty but I felt it serves as a good documentation that they're used/available.

[safern]

Makes sense. Thanks for explaining.

[safern]

Other than a few comments/questions, the infra changes LGTM.

[akoeplinger]

dotnet-runtime-perf failures are due to #33082.

[jkotas]

Does this need to be mentioned in https://github.com/dotnet/runtime/blob/master/THIRD-PARTY-NOTICES.TXT ?

[akoeplinger]

Yes, we discussed with @richlander and we'll take care of that.

[ViktorHofer]

discussed various additions to this PR offline with @akoeplinger, like the necessity of the installer subset at a later point for the runtime pack to build. The subset validation as well should be enabled later. LGTM. Thanks!

[akoeplinger]

This adds support for iOS using the Mono runtime to the build system.

I'm only adding the build integration right now, CI support will be done separately.

[filipnavara]

I'd expect iOS to set CLR_CMAKE_TARGET_DARWIN too. Not sure whether it would make the rest of the diff with if conditions smaller or larger though.

[am11]

Yes please, at least on cmake side, we are consistent with Darwin naming. It's only the code and RIDs where the (obsolete) osx name is used. 😁

[akoeplinger]

This was a conscious decision because CLR_CMAKE_TARGET_DARWIN really means macOS in the rest of the build scripts. We could rename it to CLR_CMAKE_TARGET_OSX?

[akoeplinger]

I'll do the renaming in a follow-up PR.

[bartonjs]

What's the minimum target iOS? 9 stopped getting patches 3 years ago (modulo one patch for GPS rollover last year). Even 10 looks to be out of support other than the GPS fix.

[akoeplinger]

The minimum target that Xamarin supports today is iOS 7 for devices and iOS 8 for the simulator so I replicated that here. We're discussing with PM but it looks like we won't be able to meaningfully bump the minimum version, definitely not to 10.

[marek-safar]

@ViktorHofer any objections?

[ViktorHofer]

I hadn't yet that time to review the PR. Please wait until #33242 is in (should be in ~1 hour) on which I was working the last few days to avoid conflicts. I will now review the PR.

[akoeplinger]

Sure. I'll need to push another merge anyway due to conflicts so I can wait for that PR to land.

[ViktorHofer]

@ViktorHofer any objections?

a lot's going on today. I just requested review from dotnet/runtime-infrastructure as well. I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable. Please don't merge the change yet before me and the infra teams has taken a closer look. Thanks for your understanding.

[akoeplinger]

I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable.

@ViktorHofer let me know if what I proposed in #33292 (comment) makes more sense, thanks.

[directhex]

I'm branching off this to try and get the AzDO YAML going. Will rebase as and when.

[am11]

Could we instead:

Suggested change

	if(NOT CLR_CMAKE_CONFIGURE_PLATFORM_INCLUDED)
	message(FATAL_ERROR"configuretools.cmake needs to be included after configureplatforms.cmake")
	endif()
	include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)

and remove three occurrences of include(${CLR_ENG_NATIVE_DIR}/configureplatform.cmake) under :/src/? This way we would only use configuretools.cmake as an entrypoint cmake for eng/native (and rest of the files will become internal detail, which however may get refactored in the future).

[am11]

or perhaps for all call sites, we can add an explicit :/eng/native/entrypoint.cmake enlisting:

include(${CMAKE_CURRENT_LIST_DIR}/functions.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configuretools.cmake)

[akoeplinger]

Yes I think this makes sense. I'd prefer if we do it in a separate PR though :)

[am11]

I have addressed it as part of Android fixes #32800.

[steveisok]

@dotnet/runtime-infrastructure Can one or more of you give this a review? I'd like to have this merged today if possible.

[safern]

Should we error if SubsetCategory is not empty and contains either installer or coreclr when TargetOS is iOS?

[akoeplinger]

I feel like if you manually override subset category that way you deserve to get the failures :)

[safern]

I get that, but it is good to help developers get readable failures? Sometimes because of the lack of those validations we get a lot of questions, why this doesn't work, why am I getting this error, etc? We already have a target that does validation for the subset categories, if I remember correctly.

[ViktorHofer]

I think it's ok to set RuntimeFlavor based on the passed in SubsetCategory but I don't think that SubsetCategory should be inferred from TargetOS. The SubsetCategory can also contain values like mono, or mono-coreclr-libraries-installer therefore I think it's necessary to be intentional here and require the category to be passed in.

[akoeplinger]

@ViktorHofer why not? coreclr or installer are not valid subset categories when you have TargetOS=iOS so having a default when nothing is set explicitly makes a lot of sense.

[ViktorHofer]

I thought about this more. I'm fine with providing a default value for the subset categories when a configuration is passed in that isn't supported on one of those categories but I would not want to exclude installer which brings me back to my question: Why did you choose mono-libraries and not mono-libraries-installer?

[akoeplinger]

@ViktorHofer installer doesn't make sense at all, there won't be an installer for the iOS bits (nuget only). The default of mono-libraries is everything that we want to build by default.

[akoeplinger]

I can move the change to set DefaultSubsetCategories for TargetOS==iOS instead if that helps making it clearer.

[akoeplinger]

I discussed this with Viktor offline and there was some misunderstanding. installer is not just for building the .deb/.msi/.pkg installers but also does other things like creating runtime packs and ref packs. So we might eventually need it for iOS too.

[akoeplinger]

Regarding the subset validation: Viktor and me took a look and it seems a little more complicated to add than expected. We'll do it in a separate PR.

[safern]

Just curious, why are these set to empty?

[akoeplinger]

Some Apple tools embed certain pieces of metadata differently depending on whether you build against /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk or /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk (the former is a symlink to the latter).

On CI we want to build with the explicit version so we pass in the versions installed on the bots. Locally we don't really care about that and hardcoding the version in the file would just mean you need to change it whenever Xcode is updated, so we rely on the symlink there.

I know MSBuild doesn't require you to declare properties if they're empty but I felt it serves as a good documentation that they're used/available.

[safern]

Makes sense. Thanks for explaining.

[safern]

Other than a few comments/questions, the infra changes LGTM.

[akoeplinger]

dotnet-runtime-perf failures are due to #33082.

[jkotas]

Does this need to be mentioned in https://github.com/dotnet/runtime/blob/master/THIRD-PARTY-NOTICES.TXT ?

[akoeplinger]

Yes, we discussed with @richlander and we'll take care of that.

[ViktorHofer]

discussed various additions to this PR offline with @akoeplinger, like the necessity of the installer subset at a later point for the runtime pack to build. The subset validation as well should be enabled later. LGTM. Thanks!

[akoeplinger]

This adds support for iOS using the Mono runtime to the build system.

I'm only adding the build integration right now, CI support will be done separately.

[filipnavara]

I'd expect iOS to set CLR_CMAKE_TARGET_DARWIN too. Not sure whether it would make the rest of the diff with if conditions smaller or larger though.

[am11]

Yes please, at least on cmake side, we are consistent with Darwin naming. It's only the code and RIDs where the (obsolete) osx name is used. 😁

[akoeplinger]

This was a conscious decision because CLR_CMAKE_TARGET_DARWIN really means macOS in the rest of the build scripts. We could rename it to CLR_CMAKE_TARGET_OSX?

[akoeplinger]

I'll do the renaming in a follow-up PR.

[bartonjs]

What's the minimum target iOS? 9 stopped getting patches 3 years ago (modulo one patch for GPS rollover last year). Even 10 looks to be out of support other than the GPS fix.

[akoeplinger]

The minimum target that Xamarin supports today is iOS 7 for devices and iOS 8 for the simulator so I replicated that here. We're discussing with PM but it looks like we won't be able to meaningfully bump the minimum version, definitely not to 10.

[marek-safar]

@ViktorHofer any objections?

[ViktorHofer]

I hadn't yet that time to review the PR. Please wait until #33242 is in (should be in ~1 hour) on which I was working the last few days to avoid conflicts. I will now review the PR.

[akoeplinger]

Sure. I'll need to push another merge anyway due to conflicts so I can wait for that PR to land.

[ViktorHofer]

@ViktorHofer any objections?

a lot's going on today. I just requested review from dotnet/runtime-infrastructure as well. I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable. Please don't merge the change yet before me and the infra teams has taken a closer look. Thanks for your understanding.

[akoeplinger]

I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable.

@ViktorHofer let me know if what I proposed in #33292 (comment) makes more sense, thanks.

[directhex]

I'm branching off this to try and get the AzDO YAML going. Will rebase as and when.

[am11]

Could we instead:

Suggested change

	if(NOT CLR_CMAKE_CONFIGURE_PLATFORM_INCLUDED)
	message(FATAL_ERROR"configuretools.cmake needs to be included after configureplatforms.cmake")
	endif()
	include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)

and remove three occurrences of include(${CLR_ENG_NATIVE_DIR}/configureplatform.cmake) under :/src/? This way we would only use configuretools.cmake as an entrypoint cmake for eng/native (and rest of the files will become internal detail, which however may get refactored in the future).

[am11]

or perhaps for all call sites, we can add an explicit :/eng/native/entrypoint.cmake enlisting:

include(${CMAKE_CURRENT_LIST_DIR}/functions.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configuretools.cmake)

[akoeplinger]

Yes I think this makes sense. I'd prefer if we do it in a separate PR though :)

[am11]

I have addressed it as part of Android fixes #32800.

[steveisok]

@dotnet/runtime-infrastructure Can one or more of you give this a review? I'd like to have this merged today if possible.

[safern]

Should we error if SubsetCategory is not empty and contains either installer or coreclr when TargetOS is iOS?

[akoeplinger]

I feel like if you manually override subset category that way you deserve to get the failures :)

[safern]

I get that, but it is good to help developers get readable failures? Sometimes because of the lack of those validations we get a lot of questions, why this doesn't work, why am I getting this error, etc? We already have a target that does validation for the subset categories, if I remember correctly.

[ViktorHofer]

I think it's ok to set RuntimeFlavor based on the passed in SubsetCategory but I don't think that SubsetCategory should be inferred from TargetOS. The SubsetCategory can also contain values like mono, or mono-coreclr-libraries-installer therefore I think it's necessary to be intentional here and require the category to be passed in.

[akoeplinger]

@ViktorHofer why not? coreclr or installer are not valid subset categories when you have TargetOS=iOS so having a default when nothing is set explicitly makes a lot of sense.

[ViktorHofer]

I thought about this more. I'm fine with providing a default value for the subset categories when a configuration is passed in that isn't supported on one of those categories but I would not want to exclude installer which brings me back to my question: Why did you choose mono-libraries and not mono-libraries-installer?

[akoeplinger]

@ViktorHofer installer doesn't make sense at all, there won't be an installer for the iOS bits (nuget only). The default of mono-libraries is everything that we want to build by default.

[akoeplinger]

I can move the change to set DefaultSubsetCategories for TargetOS==iOS instead if that helps making it clearer.

[akoeplinger]

I discussed this with Viktor offline and there was some misunderstanding. installer is not just for building the .deb/.msi/.pkg installers but also does other things like creating runtime packs and ref packs. So we might eventually need it for iOS too.

[akoeplinger]

Regarding the subset validation: Viktor and me took a look and it seems a little more complicated to add than expected. We'll do it in a separate PR.

[safern]

Just curious, why are these set to empty?

[akoeplinger]

Some Apple tools embed certain pieces of metadata differently depending on whether you build against /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk or /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk (the former is a symlink to the latter).

On CI we want to build with the explicit version so we pass in the versions installed on the bots. Locally we don't really care about that and hardcoding the version in the file would just mean you need to change it whenever Xcode is updated, so we rely on the symlink there.

I know MSBuild doesn't require you to declare properties if they're empty but I felt it serves as a good documentation that they're used/available.

[safern]

Makes sense. Thanks for explaining.

[safern]

Other than a few comments/questions, the infra changes LGTM.

[akoeplinger]

dotnet-runtime-perf failures are due to #33082.

[jkotas]

Does this need to be mentioned in https://github.com/dotnet/runtime/blob/master/THIRD-PARTY-NOTICES.TXT ?

[akoeplinger]

Yes, we discussed with @richlander and we'll take care of that.

[ViktorHofer]

discussed various additions to this PR offline with @akoeplinger, like the necessity of the installer subset at a later point for the runtime pack to build. The subset validation as well should be enabled later. LGTM. Thanks!

[akoeplinger]

This adds support for iOS using the Mono runtime to the build system.

I'm only adding the build integration right now, CI support will be done separately.

[filipnavara]

I'd expect iOS to set CLR_CMAKE_TARGET_DARWIN too. Not sure whether it would make the rest of the diff with if conditions smaller or larger though.

[am11]

Yes please, at least on cmake side, we are consistent with Darwin naming. It's only the code and RIDs where the (obsolete) osx name is used. 😁

[akoeplinger]

This was a conscious decision because CLR_CMAKE_TARGET_DARWIN really means macOS in the rest of the build scripts. We could rename it to CLR_CMAKE_TARGET_OSX?

[akoeplinger]

I'll do the renaming in a follow-up PR.

[bartonjs]

What's the minimum target iOS? 9 stopped getting patches 3 years ago (modulo one patch for GPS rollover last year). Even 10 looks to be out of support other than the GPS fix.

[akoeplinger]

The minimum target that Xamarin supports today is iOS 7 for devices and iOS 8 for the simulator so I replicated that here. We're discussing with PM but it looks like we won't be able to meaningfully bump the minimum version, definitely not to 10.

[marek-safar]

@ViktorHofer any objections?

[ViktorHofer]

I hadn't yet that time to review the PR. Please wait until #33242 is in (should be in ~1 hour) on which I was working the last few days to avoid conflicts. I will now review the PR.

[akoeplinger]

Sure. I'll need to push another merge anyway due to conflicts so I can wait for that PR to land.

[ViktorHofer]

@ViktorHofer any objections?

a lot's going on today. I just requested review from dotnet/runtime-infrastructure as well. I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable. Please don't merge the change yet before me and the infra teams has taken a closer look. Thanks for your understanding.

[akoeplinger]

I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable.

@ViktorHofer let me know if what I proposed in #33292 (comment) makes more sense, thanks.

[directhex]

I'm branching off this to try and get the AzDO YAML going. Will rebase as and when.

[am11]

Could we instead:

Suggested change

	if(NOT CLR_CMAKE_CONFIGURE_PLATFORM_INCLUDED)
	message(FATAL_ERROR"configuretools.cmake needs to be included after configureplatforms.cmake")
	endif()
	include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)

and remove three occurrences of include(${CLR_ENG_NATIVE_DIR}/configureplatform.cmake) under :/src/? This way we would only use configuretools.cmake as an entrypoint cmake for eng/native (and rest of the files will become internal detail, which however may get refactored in the future).

[am11]

or perhaps for all call sites, we can add an explicit :/eng/native/entrypoint.cmake enlisting:

include(${CMAKE_CURRENT_LIST_DIR}/functions.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configuretools.cmake)

[akoeplinger]

Yes I think this makes sense. I'd prefer if we do it in a separate PR though :)

[am11]

I have addressed it as part of Android fixes #32800.

[steveisok]

@dotnet/runtime-infrastructure Can one or more of you give this a review? I'd like to have this merged today if possible.

[safern]

Should we error if SubsetCategory is not empty and contains either installer or coreclr when TargetOS is iOS?

[akoeplinger]

I feel like if you manually override subset category that way you deserve to get the failures :)

[safern]

I get that, but it is good to help developers get readable failures? Sometimes because of the lack of those validations we get a lot of questions, why this doesn't work, why am I getting this error, etc? We already have a target that does validation for the subset categories, if I remember correctly.

[ViktorHofer]

I think it's ok to set RuntimeFlavor based on the passed in SubsetCategory but I don't think that SubsetCategory should be inferred from TargetOS. The SubsetCategory can also contain values like mono, or mono-coreclr-libraries-installer therefore I think it's necessary to be intentional here and require the category to be passed in.

[akoeplinger]

@ViktorHofer why not? coreclr or installer are not valid subset categories when you have TargetOS=iOS so having a default when nothing is set explicitly makes a lot of sense.

[ViktorHofer]

I thought about this more. I'm fine with providing a default value for the subset categories when a configuration is passed in that isn't supported on one of those categories but I would not want to exclude installer which brings me back to my question: Why did you choose mono-libraries and not mono-libraries-installer?

[akoeplinger]

@ViktorHofer installer doesn't make sense at all, there won't be an installer for the iOS bits (nuget only). The default of mono-libraries is everything that we want to build by default.

[akoeplinger]

I can move the change to set DefaultSubsetCategories for TargetOS==iOS instead if that helps making it clearer.

[akoeplinger]

I discussed this with Viktor offline and there was some misunderstanding. installer is not just for building the .deb/.msi/.pkg installers but also does other things like creating runtime packs and ref packs. So we might eventually need it for iOS too.

[akoeplinger]

Regarding the subset validation: Viktor and me took a look and it seems a little more complicated to add than expected. We'll do it in a separate PR.

[safern]

Just curious, why are these set to empty?

[akoeplinger]

Some Apple tools embed certain pieces of metadata differently depending on whether you build against /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk or /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk (the former is a symlink to the latter).

On CI we want to build with the explicit version so we pass in the versions installed on the bots. Locally we don't really care about that and hardcoding the version in the file would just mean you need to change it whenever Xcode is updated, so we rely on the symlink there.

I know MSBuild doesn't require you to declare properties if they're empty but I felt it serves as a good documentation that they're used/available.

[safern]

Makes sense. Thanks for explaining.

[safern]

Other than a few comments/questions, the infra changes LGTM.

[akoeplinger]

dotnet-runtime-perf failures are due to #33082.

[jkotas]

Does this need to be mentioned in https://github.com/dotnet/runtime/blob/master/THIRD-PARTY-NOTICES.TXT ?

[akoeplinger]

Yes, we discussed with @richlander and we'll take care of that.

[ViktorHofer]

discussed various additions to this PR offline with @akoeplinger, like the necessity of the installer subset at a later point for the runtime pack to build. The subset validation as well should be enabled later. LGTM. Thanks!

[akoeplinger]

This adds support for iOS using the Mono runtime to the build system.

I'm only adding the build integration right now, CI support will be done separately.

[filipnavara]

I'd expect iOS to set CLR_CMAKE_TARGET_DARWIN too. Not sure whether it would make the rest of the diff with if conditions smaller or larger though.

[am11]

Yes please, at least on cmake side, we are consistent with Darwin naming. It's only the code and RIDs where the (obsolete) osx name is used. 😁

[akoeplinger]

This was a conscious decision because CLR_CMAKE_TARGET_DARWIN really means macOS in the rest of the build scripts. We could rename it to CLR_CMAKE_TARGET_OSX?

[akoeplinger]

I'll do the renaming in a follow-up PR.

[bartonjs]

What's the minimum target iOS? 9 stopped getting patches 3 years ago (modulo one patch for GPS rollover last year). Even 10 looks to be out of support other than the GPS fix.

[akoeplinger]

The minimum target that Xamarin supports today is iOS 7 for devices and iOS 8 for the simulator so I replicated that here. We're discussing with PM but it looks like we won't be able to meaningfully bump the minimum version, definitely not to 10.

[marek-safar]

@ViktorHofer any objections?

[ViktorHofer]

I hadn't yet that time to review the PR. Please wait until #33242 is in (should be in ~1 hour) on which I was working the last few days to avoid conflicts. I will now review the PR.

[akoeplinger]

Sure. I'll need to push another merge anyway due to conflicts so I can wait for that PR to land.

[ViktorHofer]

@ViktorHofer any objections?

a lot's going on today. I just requested review from dotnet/runtime-infrastructure as well. I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable. Please don't merge the change yet before me and the infra teams has taken a closer look. Thanks for your understanding.

[akoeplinger]

I peeked into the changes and the RuntimeFlavor one in Subsets.props is questionable.

@ViktorHofer let me know if what I proposed in #33292 (comment) makes more sense, thanks.

[directhex]

I'm branching off this to try and get the AzDO YAML going. Will rebase as and when.

[am11]

Could we instead:

Suggested change

	if(NOT CLR_CMAKE_CONFIGURE_PLATFORM_INCLUDED)
	message(FATAL_ERROR"configuretools.cmake needs to be included after configureplatforms.cmake")
	endif()
	include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)

and remove three occurrences of include(${CLR_ENG_NATIVE_DIR}/configureplatform.cmake) under :/src/? This way we would only use configuretools.cmake as an entrypoint cmake for eng/native (and rest of the files will become internal detail, which however may get refactored in the future).

[am11]

or perhaps for all call sites, we can add an explicit :/eng/native/entrypoint.cmake enlisting:

include(${CMAKE_CURRENT_LIST_DIR}/functions.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configureplatform.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/configuretools.cmake)

[akoeplinger]

Yes I think this makes sense. I'd prefer if we do it in a separate PR though :)

[am11]

I have addressed it as part of Android fixes #32800.

[steveisok]

@dotnet/runtime-infrastructure Can one or more of you give this a review? I'd like to have this merged today if possible.

[safern]

Should we error if SubsetCategory is not empty and contains either installer or coreclr when TargetOS is iOS?

[akoeplinger]

I feel like if you manually override subset category that way you deserve to get the failures :)

[safern]

I get that, but it is good to help developers get readable failures? Sometimes because of the lack of those validations we get a lot of questions, why this doesn't work, why am I getting this error, etc? We already have a target that does validation for the subset categories, if I remember correctly.

[ViktorHofer]

I think it's ok to set RuntimeFlavor based on the passed in SubsetCategory but I don't think that SubsetCategory should be inferred from TargetOS. The SubsetCategory can also contain values like mono, or mono-coreclr-libraries-installer therefore I think it's necessary to be intentional here and require the category to be passed in.

[akoeplinger]

@ViktorHofer why not? coreclr or installer are not valid subset categories when you have TargetOS=iOS so having a default when nothing is set explicitly makes a lot of sense.

[ViktorHofer]

I thought about this more. I'm fine with providing a default value for the subset categories when a configuration is passed in that isn't supported on one of those categories but I would not want to exclude installer which brings me back to my question: Why did you choose mono-libraries and not mono-libraries-installer?

[akoeplinger]

@ViktorHofer installer doesn't make sense at all, there won't be an installer for the iOS bits (nuget only). The default of mono-libraries is everything that we want to build by default.

[akoeplinger]

I can move the change to set DefaultSubsetCategories for TargetOS==iOS instead if that helps making it clearer.

[akoeplinger]

I discussed this with Viktor offline and there was some misunderstanding. installer is not just for building the .deb/.msi/.pkg installers but also does other things like creating runtime packs and ref packs. So we might eventually need it for iOS too.

[akoeplinger]

Regarding the subset validation: Viktor and me took a look and it seems a little more complicated to add than expected. We'll do it in a separate PR.

[safern]

Just curious, why are these set to empty?

[akoeplinger]

Some Apple tools embed certain pieces of metadata differently depending on whether you build against /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk or /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.2.sdk (the former is a symlink to the latter).

On CI we want to build with the explicit version so we pass in the versions installed on the bots. Locally we don't really care about that and hardcoding the version in the file would just mean you need to change it whenever Xcode is updated, so we rely on the symlink there.

I know MSBuild doesn't require you to declare properties if they're empty but I felt it serves as a good documentation that they're used/available.

[safern]

Makes sense. Thanks for explaining.

[safern]

Other than a few comments/questions, the infra changes LGTM.

[akoeplinger]

dotnet-runtime-perf failures are due to #33082.

[jkotas]

Does this need to be mentioned in https://github.com/dotnet/runtime/blob/master/THIRD-PARTY-NOTICES.TXT ?

[akoeplinger]

Yes, we discussed with @richlander and we'll take care of that.

[ViktorHofer]

discussed various additions to this PR offline with @akoeplinger, like the necessity of the installer subset at a later point for the runtime pack to build. The subset validation as well should be enabled later. LGTM. Thanks!