Add iOS build configurations #33292

akoeplinger · 2020-03-06T17:39:24Z

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.

eng/Subsets.props

filipnavara · 2020-03-06T17:52:59Z

eng/native/configureplatform.cmake

+if(CLR_CMAKE_TARGET_OS STREQUAL iOS)
+    set(CLR_CMAKE_TARGET_UNIX 1)
+    set(CLR_CMAKE_TARGET_IOS 1)
+endif(CLR_CMAKE_TARGET_OS STREQUAL iOS)


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.

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. 😁

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?

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

src/libraries/Native/Unix/System.Security.Cryptography.Native/CMakeLists.txt

bartonjs · 2020-03-06T18:18:46Z

src/libraries/Native/Unix/configure.cmake

+    # Manually set results from check_c_source_runs() since it's not possible to actually run it during CMake configure checking
+    unset(HAVE_SHM_OPEN_THAT_WORKS_WELL_ENOUGH_WITH_MMAP)
+    unset(HAVE_CLOCK_MONOTONIC) # only exists on iOS 10+
+    unset(HAVE_CLOCK_REALTIME)  # only exists on iOS 10+


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.

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.

...aries/System.Security.Cryptography.Encoding/src/System.Security.Cryptography.Encoding.csproj

# Conflicts: # src/libraries/pkg/Directory.Build.props # src/mono/netcore/nuget/Directory.Build.props

It is only used for interacting with OpenSSL which isn't useful on iOS.

marek-safar · 2020-03-10T11:55:04Z

@ViktorHofer any objections?

ViktorHofer · 2020-03-10T12:21:08Z

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.

# Conflicts: # eng/native/configuretools.cmake # src/installer/corehost/CMakeLists.txt # src/libraries/System.Net.NetworkInformation/src/System.Net.NetworkInformation.csproj

akoeplinger · 2020-03-10T12:45:06Z

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

ViktorHofer · 2020-03-10T14:22:53Z

@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 · 2020-03-10T14:32:54Z

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 · 2020-03-10T14:34:16Z

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

am11 · 2020-03-10T14:45:06Z

eng/native/configuretools.cmake

+if(NOT CLR_CMAKE_CONFIGURE_PLATFORM_INCLUDED)
+  message(FATAL_ERROR "configuretools.cmake needs to be included after configureplatforms.cmake")
+endif()


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).

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)

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

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

src/libraries/Directory.Build.props

src/libraries/restore/runtime/runtime.depproj

# Conflicts: # src/libraries/Directory.Build.props

steveisok · 2020-03-11T17:34:33Z

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

safern · 2020-03-11T17:42:19Z

eng/Subsets.props

@@ -66,6 +66,7 @@

    <_subsetCategory Condition="'$(SubsetCategory)' != ''">$(SubsetCategory.ToLowerInvariant())</_subsetCategory>
    <_subsetCategory Condition="'$(SubsetCategory)' == ''">$(DefaultSubsetCategories)</_subsetCategory>
+    <_subsetCategory Condition="'$(SubsetCategory)' == '' and '$(TargetOS)' == 'iOS'">libraries-mono</_subsetCategory>


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

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

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.

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.

@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.

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?

@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.

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

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.

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.

eng/native/naming.props

src/libraries/Native/build-native.sh

src/libraries/System.Net.Http/tests/UnitTests/System.Net.Http.Unit.Tests.csproj

src/libraries/System.Net.NetworkInformation/src/System.Net.NetworkInformation.csproj

src/libraries/System.Net.Security/src/System.Net.Security.csproj

safern · 2020-03-11T17:55:45Z

src/mono/Directory.Build.props

+    <watchOS64_32VersionMin>5.1</watchOS64_32VersionMin>
+    <macOSVersionMin>10.13</macOSVersionMin>
+
+    <!-- Version of the OS SDK we target -->


Just curious, why are these set to empty?

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.

Makes sense. Thanks for explaining.

safern

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

akoeplinger · 2020-03-11T23:55:15Z

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

jkotas · 2020-03-12T03:58:04Z

src/libraries/Native/Unix/System.Native/ios/net/route.h

@@ -0,0 +1,272 @@
+/*
+ * Copyright (c) 2000-2008 Apple Inc. All rights reserved.


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

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!

This is based on #33292

Add iOS build configurations

3ab2446

Dotnet-GitSync-Bot added the area-Infrastructure-libraries label Mar 6, 2020

akoeplinger commented Mar 6, 2020

View reviewed changes

eng/Subsets.props Show resolved Hide resolved

filipnavara reviewed Mar 6, 2020

View reviewed changes

bartonjs reviewed Mar 6, 2020

View reviewed changes

src/libraries/Native/Unix/System.Security.Cryptography.Native/CMakeLists.txt Outdated Show resolved Hide resolved

bartonjs reviewed Mar 6, 2020

View reviewed changes

...aries/System.Security.Cryptography.Encoding/src/System.Security.Cryptography.Encoding.csproj Show resolved Hide resolved

akoeplinger added 5 commits March 9, 2020 16:34

Merge remote-tracking branch 'upstream/master' into fix-add-ios

3ed6789

# Conflicts: # src/libraries/pkg/Directory.Build.props # src/mono/netcore/nuget/Directory.Build.props

Don't build System.Security.Cryptography.Native library on iOS

4543209

It is only used for interacting with OpenSSL which isn't useful on iOS.

Fix desktop mono build

9c051a9

Fix Mono packaging build

06cd416

Fix Mono Windows build

7f8d779

akoeplinger marked this pull request as ready for review March 9, 2020 17:53

akoeplinger requested review from alexischr, CoffeeFlux, EgorBo, lambdageek, lewurm, marek-safar, steveisok, thaystg and vargaz as code owners March 9, 2020 17:53

marek-safar approved these changes Mar 10, 2020

View reviewed changes

Merge remote-tracking branch 'upstream/master' into add-ios

804c34d

# Conflicts: # eng/native/configuretools.cmake # src/installer/corehost/CMakeLists.txt # src/libraries/System.Net.NetworkInformation/src/System.Net.NetworkInformation.csproj

akoeplinger added 3 commits March 10, 2020 13:52

Merge remote-tracking branch 'upstream/master' into add-ios

4e10780

Fix disabling of System.Security.Cryptography.Native on iOS

7b1cbaa

Fix build after merge of dotnet#33242

ab6b26b

ViktorHofer requested a review from a team March 10, 2020 14:21

directhex mentioned this pull request Mar 10, 2020

Add AzDO builds for iOS #33424

Merged

am11 reviewed Mar 10, 2020

View reviewed changes

safern reviewed Mar 10, 2020

View reviewed changes

src/libraries/Directory.Build.props Show resolved Hide resolved

safern reviewed Mar 10, 2020

View reviewed changes

src/libraries/restore/runtime/runtime.depproj Outdated Show resolved Hide resolved

akoeplinger added 3 commits March 11, 2020 12:27

Fix typo in error message

ca62be6

PR feedback

810ffcf

Merge remote-tracking branch 'upstream/master' into fix-add-ios

c074d97

# Conflicts: # src/libraries/Directory.Build.props