Add AzDO builds for iOS

[directhex]

This is based on #33292

[directhex]

Dang I meant to make this a draft

[directhex]

@marek-safar on iOS only, or on OSX as well?

[marek-safar]

ios only

[directhex]

Well, this seems to be doing the expected thing?

[marek-safar]

You need to hook up libraries build as well

[directhex]

@marek-safar ok, looks like I wired in iOS Libraries. This still needs rebasing against the final version of #33292 but the AzDO logic seems sound

[directhex]

OK, I rebuilt the branch against master post-merge. Let's see what happens

[directhex]

Yeah that's looking OK. Ready for review I reckon.

[akoeplinger]

@directhex can you try doing an official build to make sure it works there too?

[directhex]

@akoeplinger not until darc starts working again!

[directhex]

@safern I can't reproduce the failure in the official build - https://dev.azure.com/dnceng/7ea9116e-9fac-403d-b258-b31fcf1bb293/_apis/build/builds/558857/logs/261

Suggestions?

[safern]

it seems like you're somehow missing an space in between iOS and -stripSymbols? I see this is how build-native.sh is being called.

/Users/runner/runners/2.165.0/work/1/s/src/libraries/Native/build-native.sh x64 Release outconfig netcoreapp5.0-iOS-Release-x64 -os iOS-stripSymbols

[directhex]

@safern I've figured out why that's happening, and could use input from @Anipik & @ViktorHofer to understand the right way to fix it (i.e. what the expected behaviour is supposed to be)

In eng/pipelines/libraries/base-job.yml, the variable _stripSymbolsArg is conditionally defined as -stripSymbols on non-Windows. It is then passed as a parameter to ./libraries.sh, i.e. I get a run of ./libraries.sh -build -configuration Release -ci -arch x64 -stripSymbols -os iOS /p:OfficialBuildId=20200316.5 /p:RuntimeArtifactsPath=/Users/runner/runners/2.165.0/work/1/s/artifacts/transport/coreclr - however, all variables in AzDO are exported as environment... so in src/libraries/Native/build-native.proj, _stripSymbolsArg is redefined as -stripsymbols (note the leading space) only when BuildNativeStripSymbols is true, and TargetOS is NOT wasm (or iOS in the specific case of this PR).

As a result, during command line construction in build-native.proj, $(_BuildNativeArgs)$(_ProcessCountArg)$(_StripSymbolsArg) has a leading space on _StripSymbolsArg only when TargetOS is NOT iOS/wasm, or when reproducing locally (when you aren't going to be exporting the no-space value from the YAML)

Is the expectation that -stripSymbols should be EMPTY on iOS, or not? (if not, why is it in the conditional in build-native.proj)

[safern]

Arrgg I hate when that happens 😠

So I would leave -stripSymbols definition in the yml with the current conditions as is and without any quotes or spaces. What I would recommend doing is just rename the yml variable to be, _stripSymbolsArgYaml and add a comment on why the name and to not rename.

Yes based on what @akoeplinger the expectation is that -stripSymbolsArg is empty for iOS. So I would also condition it when setting it in the yml to when osGroup != iOS.

[directhex]

I guess same question to @akoeplinger, who added ios to the same conditional as wasm - should symbol stripping happen or not on iOS?

[directhex]

OK, 'Mismatched MVIDs in ibc data' means nothing to me

https://dev.azure.com/dnceng/7ea9116e-9fac-403d-b258-b31fcf1bb293/_apis/build/builds/561059/logs/288

[akoeplinger]

should symbol stripping happen or not on iOS?

I didn't really know which is why I just copied webassembly for now 😄

[directhex]

I think the answer is "no" because the symbol stripping depends on objcopy, which isn't available in this scenario

[akoeplinger]

Failures are unrelated, merging.