* [configure] Add --[enable|disable]-dotnet.
And make it enabled by default on CI and disabled by default elsewhere for now
(because it makes the build significantly slower).
* [system-dependencies] Add support for provisioning .NET.
Also write a global.json in the root directory which is how we select which
.NET version to use.
We inject an x86-64 slice into binaries that don't contain one, because
Apple's notarization process fails without such a slice.
But make the slice optional and opt-in, because it seems Apple has started
to fail on binaries with such a slice now...
* [xcode11.4] Add xcode 11.4 b1 initial support
* [xtro] re-enable PDFKit
* Disable watchOS and fix xtro
Unfortunately watchOS simulator hangs when we try to deploy to it
and it keeps our tests timing out. Disabling for now until we
can investigate more.
Disables PDFKit on xtro in macOS
* [jenkins] Switch to use the catalina bot group (#7819)
* Bump maccore to get fix for launching the simulator for watch apps.
New commits in xamarin/maccore:
* xamarin/maccore@546270c8f9 [Xamarin.Hosting] Fix the name of the notification we get when the simulator has launched. (#2145)
Diff: 55957e908d..546270c8f9
* [tests] Diable watch due to time out, enable 10,15,4 in intro, fix min version
* Bump macios-binaries to get updated binary mlaunch as well.
New commits in xamarin/macios-binaries:
* xamarin/macios-binaries@f8c6e63 Bump mlaunch to xamarin/maccore@546270c8f9
Diff: eb6980e8b6..f8c6e63228
* [msbuild] Reflect ibtool changes in our tests
Looks like Apple reverted some changes introduces in Xcode 11
in ibtool, for more context see xamarin/xamarin-macios#6970
* [mtouch] Workaround strange behavior of realpath.
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [Mtouch] Make sure that the given SDK version and the iOS version do match.
We need to make sure that the iOS SDK and the iOS version do match the
ones present in Xcode.
* Add new variables to track the target version.
* Add method to get the target version.
* Modify mtouch to check agains the target framework rather than the
SDK.
This will allow to keep track of three independent things:
1. The SDK max version.
2. The Simulator max version.
3. The target version of the device.
This had to be added becuase 13.2 has targets to 13.2 but simulators for
13.3
Fixes: https://github.com/xamarin/xamarin-macios/issues/7705
We need to make sure that the iOS SDK and the iOS version do match the
ones present in Xcode.
* Add new variables to track the target version.
* Add method to get the target version.
* Modify mtouch to check agains the target framework rather than the
SDK.
This will allow to keep track of three independent things:
1. The SDK max version.
2. The Simulator max version.
3. The target version of the device.
This had to be added becuase 13.2 has targets to 13.2 but simulators for
13.3
Fixes: https://github.com/xamarin/xamarin-macios/issues/7705
Make csc to bee more strict when compiling the projects and mix some
small errors we had in the bindings.
Fixes: https://github.com/xamarin/xamarin-macios/issues/5398
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* [Makefile] Make csc strict and fix some small errors.
Make csc to bee more strict when compiling the projects and mix some
small errors we had in the bindings.
Fixes: https://github.com/xamarin/xamarin-macios/issues/5398
* Fixed
`/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/builds/mono-ios-sdk-destdir/ios-sources/external/linker/src/linker/Linker.Steps/OutputStep.cs(110,15): error CS0246: The type or namespace name ‘OutputException’ could not be found (are you missing a using directive or an assembly reference?) [/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/mmp/mmp.csproj]`
* Changed the name of the method that is used from linker. Because of this commit 6be26771b9
* Added `OutputException.cs` file on `mtouch.csproj`.
* Removing enter_gc_safe and exit_gc_safe because now it's already gc_safe in this part of code, after a mono change.
* Added known exceptions to LLVM exception list.
* Needs `ifdef` because of this https://github.com/mono/mono/pull/17260.
* Bump MIN_MONO_VERSION to 6.8.0.41 and point MIN_MONO_URL to the PR.
* Add ENABLE_IOS=1 and ENABLE_MAC=1.
* Added switch to disable packaged mono build
* [Tests] Ignore tests that fail on 32b.
Ignore the test on 32b, and filled issue: https://github.com/mono/mono/issues/17752
* [Tests] Ignore a couple of tests causing OOM.
Hopefully fixes https://github.com/xamarin/maccore/issues/1659 for good.
* Ignore `MM0135` test on Catalina+ because it needs Xcode 9.4.
* [monotouch-test] Add null checks for teardown when test didn't run because of a too early OS version.
* [CFNetwork]: Http 2.0 requires OS X 10.11 or later.
Check whether `_HTTPVersion2_0` is available and fallback to HTTP 1.1 otherwise.
* #7346
* This bumps Mono to use https://github.com/mono/mono/pull/17645 (which is the 2019-10 backport
of https://github.com/mono/mono/pull/17628).
* The big user-visible change is in regards to certificate validation, everything below are just
some minor adjustments to tests.
CoreFX uses a completely new `HttpClientHandler` implementation called `SocketsHttpHandler`,
which you can find at https://github.com/dotnet/corefx/tree/release/3.0/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler.
Since this is not based on the web stack anymore, it does not use any of the related APIs such
as `ServicePointManager` or `WebException`.
There is a new API called `HttpClientHandler.ServerCertificateCustomValidationCallback`.
- https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.servercertificatecustomvalidationcallback?view=netframework-4.8
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Unix.cs (L154)
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Windows.cs (L383)
The `ServicePointManager.ServerCertificateValidationCallback` is no longer invoked and on
certificate validation failure, `AuthenticationException` (from `System.Security.Authentication`)
is thrown instead of `WebException`.
At the moment, the `NSUrlSessionHandler` still uses it's own validation callback and also still
throws `WebException` on failure; we should probably look into making this consistent with the
other handlers.
* `HttpContent.SerializeToStreamAsync()` is now `protected` (changed from `protected internal`).
- src/Foundation/NSUrlSessionHandler.cs: changed overload accordingly.
- src/System.Net.Http/CFContentStream.cs: likewise.
* `HttpHeaders.GetKnownHeaderKind()` is an internal Mono API.
There is a new internal API called `System.Net.Http.PlatformHelper.IsContentHeader(key)`
which exists in both the old as well as the new implementation.
The correct way of doing it with the CoreFX handler is
`HeaderDescriptor.TryGet (key, out var descriptor) && descriptor.HeaderType == HttpHeaderType.Content`
* `HttpClientHandler.MaxRequestContentBufferSize` is now longer supported, you can set it to
any non-negative value, the getter will always return 0.
See c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Core.cs (L18).
- tests/linker/ios/link sdk/HttpClientHandlerTest.cs: removed assertion from test.
* `HttpMessageInvoker.handler` is a `protected private` field - in the CoreFX handler, it is
called `_handler` and `private`. This is accessed via reflection by some of the tests, which are
now using the new name.
- tests/mmptest/src/MMPTest.cs: here
- tests/mtouch/MTouch.cs: here
* tests/monotouch-test/System.Net.Http/MessageHandlers.cs:
Adjust `RejectSslCertificatesServicePointManager` to reflect the certificate validation
changes described above.
- FIXME: There was an `Assert.Ignore()` related to `NSUrlSessionHandler` and macOS 10.10;
I removed that to reenable the test because the description linked to an old issue in
the private repo that was referenced by several "Merged" PR's, so it looked to me that
this might have already been fixed - and I also didn't see why it would fail there.
## Miscellaneous fixes
* Fixed
`/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/builds/mono-ios-sdk-destdir/ios-sources/external/linker/src/linker/Linker.Steps/OutputStep.cs(110,15): error CS0246: The type or namespace name ‘OutputException’ could not be found (are you missing a using directive or an assembly reference?) [/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/mmp/mmp.csproj]`
* Changed the name of the method that is used from linker. Because of this commit 6be26771b9
* Added `OutputException.cs` file on `mtouch.csproj`.
* Removing enter_gc_safe and exit_gc_safe because now it's already gc_safe in this part of code, after a mono change.
* Added known exceptions to LLVM exception list.
* Needs `ifdef` because of this https://github.com/mono/mono/pull/17260.
* Bump MIN_MONO_VERSION to 6.8.0.41 and point MIN_MONO_URL to the PR.
* Add ENABLE_IOS=1 and ENABLE_MAC=1.
* Added switch to disable packaged mono build
* [Tests] Ignore tests that fail on 32b.
Ignore the test on 32b, and filled issue: https://github.com/mono/mono/issues/17752
* [Tests] Ignore a couple of tests causing OOM.
Hopefully fixes https://github.com/xamarin/maccore/issues/1659 for good.
* Ignore `MM0135` test on Catalina+ because it needs Xcode 9.4.
* [monotouch-test] Add null checks for teardown when test didn't run because of a too early OS version.
* [CFNetwork]: Http 2.0 requires OS X 10.11 or later.
Check whether `_HTTPVersion2_0` is available and fallback to HTTP 1.1 otherwise.
## Bring HttpClient from CoreFX
* #7346
* This bumps Mono to use https://github.com/mono/mono/pull/17645 (which is the 2019-10 backport
of https://github.com/mono/mono/pull/17628).
* The big user-visible change is in regards to certificate validation, everything below are just
some minor adjustments to tests.
### SocketsHttpHandler
CoreFX uses a completely new `HttpClientHandler` implementation called `SocketsHttpHandler`,
which you can find at https://github.com/dotnet/corefx/tree/release/3.0/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler.
Since this is not based on the web stack anymore, it does not use any of the related APIs such
as `ServicePointManager` or `WebException`.
### Certificate Validation Changes
There is a new API called `HttpClientHandler.ServerCertificateCustomValidationCallback`.
- https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.servercertificatecustomvalidationcallback?view=netframework-4.8
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Unix.cs (L154)
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Windows.cs (L383)
The `ServicePointManager.ServerCertificateValidationCallback` is no longer invoked and on
certificate validation failure, `AuthenticationException` (from `System.Security.Authentication`)
is thrown instead of `WebException`.
At the moment, the `NSUrlSessionHandler` still uses it's own validation callback and also still
throws `WebException` on failure; we should probably look into making this consistent with the
other handlers.
### Minor adjustments related to internal Mono APIs
* `HttpContent.SerializeToStreamAsync()` is now `protected` (changed from `protected internal`).
- src/Foundation/NSUrlSessionHandler.cs: changed overload accordingly.
- src/System.Net.Http/CFContentStream.cs: likewise.
* `HttpHeaders.GetKnownHeaderKind()` is an internal Mono API.
There is a new internal API called `System.Net.Http.PlatformHelper.IsContentHeader(key)`
which exists in both the old as well as the new implementation.
The correct way of doing it with the CoreFX handler is
`HeaderDescriptor.TryGet (key, out var descriptor) && descriptor.HeaderType == HttpHeaderType.Content`
### Minor adjustments to tests.
* `HttpClientHandler.MaxRequestContentBufferSize` is now longer supported, you can set it to
any non-negative value, the getter will always return 0.
See c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Core.cs (L18).
- tests/linker/ios/link sdk/HttpClientHandlerTest.cs: removed assertion from test.
* `HttpMessageInvoker.handler` is a `protected private` field - in the CoreFX handler, it is
called `_handler` and `private`. This is accessed via reflection by some of the tests, which are
now using the new name.
- tests/mmptest/src/MMPTest.cs: here
- tests/mtouch/MTouch.cs: here
* tests/monotouch-test/System.Net.Http/MessageHandlers.cs:
Adjust `RejectSslCertificatesServicePointManager` to reflect the certificate validation
changes described above.
- FIXME: There was an `Assert.Ignore()` related to `NSUrlSessionHandler` and macOS 10.10;
I removed that to reenable the test because the description linked to an old issue in
the private repo that was referenced by several "Merged" PR's, so it looked to me that
this might have already been fixed - and I also didn't see why it would fail there.
* Bump for Xcode 11.3 beta 1
* [system-dependencies] Make it clearer what failed on the bots.
Locally we use colors to distinguish between warnings and failures, but colors
don't show up on the bots, so use text instead.
* Verbose provisioning.
* [system-dependencies] Improve simulator checks a bit.
* Non-verbose provisioning.
* [Runtime] Enable the -Wshorten-64-to-32 flag and fix all warnings.
We want to enable the -Wconversion but that will raise too many warning
for a single commit. We are enabiling one by one the flags included in
-Wconversion so that we have smaller diffs.
-Wshorten-64-to-32 adds warnings when there is a implicit conversion that
loses integer precision. We are moving all the 32 to 64 conversions to
use 64. Expecially since most of the code changed is related with sizes,
legths and params counts that are never going to be negative.
Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
Enable the -Wsign-compare which will raise issues when a comparison
between signed and unsigned values could produce an incorrect result
and fix all the raised warnings.
* Bump mono to a hash with archives and use them.
New commits in mono/mono:
* mono/mono@6af4ae7635 [2019-06][ci] Add Xcode 11.2beta2 for XI/XM Mono SDK builds
Diff: 476d72b9e3..6af4ae7635
* Bump mono to get min iOS version fix.
New commits in mono/mono:
* mono/mono@3775d5ac0a [sdks] Bump min iOS version to 7.0.
Diff: 6af4ae7635..3775d5ac0a
* [xharness] Bump mtouch tests timeout to 3h, we have a couple of new PR bots which are old and slow.
The new PR bots are late 2012 mac minis, so quite slow.
We'll be releasing from the `xcode11.1` branch, therefore we need to move to the stable version scheme (even numbers).
In addition, since Xcode is out of GM we need to update the Xcode path so the stable device bots pickup those builds.
* Automatically build mono from source if any of the archives aren't available.
* [jenkins] Show in the PR report if mono was built from source.
* [jenkins] Make sure we got everything after running configure.
* Automatically build mono from source if any of the archives aren't available.
* [jenkins] Show in the PR report if mono was built from source.
* [jenkins] Make sure we got everything after running configure.
* Drop the Xcode 9.4 dependency. (#7044)
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@beb9a1b182 [sdks] Remove the mac32 build.
* mono/mono@747a919a06 [ci] Make ios/mac sdks archive URL more predictable
* mono/mono@114013096e [ci] Build iOS/Mac Mono sdks archive using Xcode 11
* mono/mono@10a24f3ea1 Implement WriteCore and ReadCore in DeflateStream
* mono/mono@a925846b1f [offsets-tool] Install clang into the user-specific python directory. (#16933)
* mono/mono@fe64a4765e [2019-06] Bump msbuild and sdk versions to 3.0.1xx latest (#16870)
* mono/mono@7293597b90 [corlib] Fix building nunit-lite twice (#16910)
* mono/mono@1648e88687 Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16896)
* mono/mono@a6b5187d76 [metadata] Fix leaks when handling a few attributes (#16675) (#16851)
* mono/mono@7da9a041b3 [2019-06] Bump to mono/corefx@e79cf5b
* mono/mono@2b7050bdf3 [2019-06] Add RenamedEvent* to FSW sources from CoreFX (#16758)
* mono/mono@4f5ed502c6 [msbuild] pick up p4 versions
* mono/mono@f04ee2219d [2019-06][msbuid][roslyn] Bump msbuild and roslyn-binaries to pick up dotnet 3.0.100-p9 toolset
* mono/mono@6b4b99e571 Vtable [i] can be null so this should be check before use it. Fixes#16712
Diff: 7af64d1ebe..beb9a1b182
* [tests] Add a fat macOS dylib for testing purposes.
Add a binary version of a fat macOS dylib (because we can't create one when we
need it since we can't create 32-bit slice anymore).
It was created like this (in tests/test-libraries):
$ cat test.m
int theUltimateAnswer ()
{
return 42;
}
$ /Applications/Xcode94.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang test.m -olibtest.i386.dylib -shared -isysroot /Applications/Xcode94.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -framework Foundation -framework CoreLocation -lz -arch i386
$ lipo -create libtest.i386.dylib .libs/macos/libtest.dylib -output libtest-fat.dylib
* [tests] Adjust XM tests to XM not having fat dylibs anymore.
* [tests] Adjust product tests to some libraries not being fat anymore.
* [tests] Don't treat an Xcode with the same major version number as old.
Fixes an issue in the MT0091 test, where it would fail on tvOS because the
test wanted to use an older Xcode, and we could end up returning Xcode 11.0
when the current Xcode is 11.1. Since the test depends on using the OS SDK as
it was designed for (technically using an OS SDK earlier than the latest), it
ended up failing because while the iOS SDK was bumped in Xcode 11.1, the tvOS
SDK was not.
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@70d6903053 [2019-08] [merp] Use a separate program as the hang supervisor. (#16900)
* mono/mono@4bff2b6370 [offsets-tool] Install clang into the user-specific python directory.
* mono/mono@81894ec8ca Implement WriteCore and ReadCore in DeflateStream
* mono/mono@bfbf823ca1 [ci] Remove more XCODE32_DIR usages (#16964)
* mono/mono@ce01b20a4d Add net_4.8.xml to EXTRA_DIST and bump binary-reference-assemblies again
* mono/mono@7a587d7fa6 Add .NET 4.8 reference assemblies (#16912)
* mono/mono@35e454a8f6 [sdks] Remove the mac32 build. (#16936)
* mono/mono@75eb342f53 [2019-08] [System] Make FileSystemWatcher backend non-static (#16926)
* mono/mono@5881981f79 [2019-08] [mini] Add missing membars when initializing rgctx entries (#16909)
* mono/mono@6290b6cd6e Temporarily disable embedded ppdb data decompression (#16911)
* mono/mono@a0e7f9eaf2 [2019-08] [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter (#16886)
* mono/mono@6275840a7f Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16901)
* mono/mono@25f6093283 [corlib] Fix building nunit-lite twice (#16895)
* mono/mono@7ec17ba1be [2019-08] [android sdk] Add aprofutil tool (#16884)
* mono/mono@f755f3b539 [metadata] Fix leaks when handling a few attributes (#16850)
* mono/mono@5f9a2db39b [2019-08] Fix infrequent hangs in test-runner. (#16854)
* mono/mono@f31f5ea1f1 [2019-08] [threads] do not convert NULL thread name (#16828)
* mono/mono@20308e6f87 [aot] Do not wrap tool_prefix path when calling strip (#16820)
* mono/mono@cecda47c48 [aprofutil] Add -p and -f options
* mono/mono@824cc12ac3 Bump to mono/corefx@e79cf5b
* mono/mono@b77dc06a7e [aprofutil] Install the tool correctly (#16112)
* mono/mono@1848d78d60 [aotprof-tool] Initial import of AOT profiler tool (#15384)
* mono/mono@da0086e304 [2019-08] Add RenamedEvent* to FSW sources from CoreFX (#16756)
* mono/mono@0297b21b03 [msbuild][roslyn] Bump msbuild and roslyn to pull in new versions (#16768)
* mono/mono@40631e3b9e [2019-08] [aot] move method_addresses to data.rel.so section to avoid text relocations (#16751)
* mono/mono@68b77674e2 Vtable [i] can be null so this should be check before use it. Fixes#16712
* mono/mono@4a0b4f41ed [mini] publish global patches after JitInfo has been added
* mono/mono@7a1f63fde6 [debugger][android] It was not initialising seq_points on MonoCompile on Android, so when was compiling dynamic methods, seq_points wasn't created and we got the assert when try to single step.
Diff: 29b1ac19c9..70d6903053
* [tests] Add a fat macOS dylib for testing purposes.
Add a binary version of a fat macOS dylib (because we can't create one when we
need it since we can't create 32-bit slice anymore).
It was created like this (in tests/test-libraries):
$ cat test.m
int theUltimateAnswer ()
{
return 42;
}
$ /Applications/Xcode94.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang test.m -olibtest.i386.dylib -shared -isysroot /Applications/Xcode94.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -framework Foundation -framework CoreLocation -lz -arch i386
$ lipo -create libtest.i386.dylib .libs/macos/libtest.dylib -output libtest-fat.dylib
* [tests] Adjust XM tests to XM not having fat dylibs anymore.
* [tests] Adjust product tests to some libraries not being fat anymore.
* One more test fix.
It's the same hash as Xcode 11 GM 2 but it's cleaner to actually use `Xcode11.app`.
In addition: the device bots are looking for "GM" and "beta" in the Xcode name to run on either the stable or beta pool.
It's the same hash as Xcode 11 GM 2 but it's cleaner to actually use `Xcode11.app`.
In addition: the device bots are looking for "GM" and "beta" in the Xcode name to run on either the stable or beta pool.
Included changes are:
* New Cecil API in 2019-08
* Permit new symbols from networkable AOT profiler in symbols test
* Bump Mono to include fix for zlib linking, and new Cecil API
* We need to link against zlib now, if using libmono.a
* [Tests] Ignore memory hungry tests in old devices. (#6913)
* Ignore certain tests that use too many resources in old devices.
* Add missing tests that use too much memory on 32b devices.
Xcode 11 doesn't support anything below iOS 7.0 (the linker will automatically
change the deployment target to 7.0), so we need to drop support as well
(since our native bits will be targetting iOS 7.0, and we can't change that).
https://github.com/xamarin/xamarin-macios/issues/6213
* Build native code with -std=c++14.
Apple's headers now require -std=c++14 to compile their headers in C++ mode.
This fixes a compile error that would occur with the PhotosUI framework when
compiling code for C++.
* [mmp] Use -std=c++14 when compiling.
* Fix command line output.
* [mmp] Add all source files at the end, so they all get the -x clang argument applied.
* Limit when using c++14 in mtouch according to language.
* Bump for Xcode 11 beta 4
xtro tests will fail until we have an update for sharpie, however
the introspection tests should be fine (with the small changes in
arkit.cs and uikit.cs)
xtro failure:
```
System.NotImplementedException: AVAudioInteger
at (wrapper managed-to-native) Clang.Ast.AstReader.LoadInternal(Clang.Ast.AstReader,string)
at Clang.Ast.AstReader.Load (System.String astPath) [0x00014] in /Users/builder/vsts-agent/_work/5/s/Clang/Ast/AstReader.cs:33
at Extrospection.Runner.Execute (System.String pchFile, System.Collections.Generic.IEnumerable`1[T] assemblyNames) [0x0019a] in /Users/poupou/git/xcode11/xamarin-macios/tests/xtro-sharpie/Runner.cs:54
at Extrospection.MainClass.Main (System.String[] args) [0x00046] in /Users/poupou/git/xcode11/xamarin-macios/tests/xtro-sharpie/Program.cs:20
```
due to
```diff
-typedef CF_ENUM(NSInteger, AVAudioSessionErrorCode) {
+typedef CF_ENUM(AVAudioInteger, AVAudioSessionErrorCode) {
```
https://github.com/xamarin/xamarin-macios/wiki/CoreAudioTypes-iOS-xcode11-beta4
* [tests] CoreText stopped reporting error when font files are missing
* Fix xtro (EnumCheck.cs) and update its data files
* Fix xtro results (due to some local changes)
* Use the commonly used casing for `MSBuildSDKsPath` property
Handle "incorrectly" cased msbuild property names
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
* [mtouch] Whitelist new Brotli native symbols in Xamarin.Tests.Misc.PublicSymbols test
* [mtouch] Better assert in NoLLVMFailuresInWatchOS() test
We'd list the "LLVM failed" messages before even though the AOT might've crashed and the list is meaningless. Assert the exit code before that.
* [mtouch] Use new LLVM even for 32bit targets
See https://github.com/mono/mono/issues/14841 and https://github.com/mono/mono/issues/9621
* [mtouch] Work around slow LLVM in "don't link" test
See https://github.com/mono/mono/issues/14843
* Remove useless conditional
* Remove LLVM36 from Makefile
* [watch4] set right min version for arm64_32 based watch devices (#6307)
Fixes the confusion around `libmono-native*` (see for example ce5ba1e41d (commitcomment-33834491) ) when building with `MONO_BUILD_FROM_SOURCE=1`.
* reflect watchos64_32_version_min change from mono sdk
* Move mono hash info to mk/mono.mk so that existing scripts work.
* Add Makefile dependency on mono.mk where necessary
With 3e7bc29ade the Mono hash was moved from Make.config to mono.mk.
We need to add a Makefile dependency on this file wherever Make.config was used to track a Mono dependency.
* [tests] Copy mk/mono.mk to the XM test package.
* [tests] Update minOS version test after consolidating min watchOS versions everywhere.
Fixes this mtouch and mmptest failure:
1) Failed : Xamarin.Tests.ProductTests.MinOSVersion(watchOS,MinwatchOS,WatchOSSimulator,False)
Failures
Expected: <empty>
But was: < "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (mono-runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-generated-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (shared-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-invoke-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (xamarin-support-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (nsstring-localization-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-varargs-debug.arm64_32.o)."... >
* [mmp] Fix make clean target
It needs an -r to remove directories:
```
rm: bin: is a directory
rm: obj: is a directory
```
* Add new xamarin_timezone_get_local_name() to a few more places
Many people are running into problems building xcode11 because they have to
"./configure --disable-packaged-mono" first.
So disable the packaged mono by default (and add a way to enable it again
manually with "./configure--disable-packaged-mono=no").
* Bump VSMac to 8.1.0.2742 to fix msbuild issues (#6279)
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
* [xibuild] Fix incorrect mscorlib.dll being used (#6068)
* [xibuild] Fix incorrect mscorlib.dll being used
The `GuiUnit_NET_4_5` project, when built with `xibuild` uses the wrong `mscorlib.dll`.
From https://github.com/xamarin/xamarin-macios/issues/5760#issuecomment-472457202 :
```
- mscorlib.dll is being used from mono/4.5 and the other system assemblies are from mono/4.5-api
- GuiNet* project is built with xibuild
What is happening here is:
xibuild sets[1] `SetToolsetProperty ("TargetFrameworkRootPath", FrameworksDirectory + Path.DirectorySeparatorChar);`
which points to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`.
This causes $(FrameworkPathOverride) to be set[2] to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks/.NETFramework/v4.5`,
but that doesn't have a mscorlib.dll, so it gets reset[3] to /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5/.
If we don't set TargetFrameworkRoothPath, then we get `FrameworkPathOverride = /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api`,
causing `_ExplicitReference=/Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api/mscorlib.dll`(correct one) to be used.
```
Fixes https://github.com/xamarin/xamarin-macios/issues/5760
1. https://github.com/xamarin/xamarin-macios/blob/master/tools/xibuild/Main.cs#L209
2. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L79
3. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L84
* Revert "Workaround https://github.com/xamarin/xamarin-macios/issues/5760 in generator csproj"
This reverts commit 9bd927bb7f.
The previous commit for xibuild removes the need for this.
* [xibuild] Handle "incorrectly" cased msbuild property names (#6202)
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
Fixed to ignore case.
Fixes https://github.com/mono/mono/issues/14765 .
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
* We must bump the min simulator versions, since Apple has bumped what they offer.
* Re-enable simulator provisioning.
* Minor output fix to siminstaller to make the output easier to understand.
This should solve the msbuild failures when recent system mono are used
to build the tests
Fix https://github.com/mono/mono/issues/14875
Also revert MAX_MONO_VERSION change from https://github.com/xamarin/xamarin-macios/pull/6221 since we should be able to use a newer mono with the VS4M bump
And bump the system mono to 6.0.0.286 (which was failing in previous builds)
Allows to build the project using XCode 11. In order to do so until we
get the mono SDK built in the bots with the Xcode 11 you need to set the
env var MONO_BUILD_FROM_SOURCE=1 so that you build mono in your system.
The system-dependencies.sh script greps in Make.config for the
EXTRA_SIMULATORS variable, and the grepping wasn't able to correctly parse the
previous variable definition, so make it simpler so that
system-dependencies.sh understands it.
The system-dependencies.sh script greps in Make.config for the
EXTRA_SIMULATORS variable, and the grepping wasn't able to correctly parse the
previous variable definition, so make it simpler so that
system-dependencies.sh understands it.
* [builds] Move the facade check targets down in the Makefile.
Move the facade check targets below the declaration of their prerequisite
variables (*_BCL_TARGETS), since otherwise the prerequisite variable will be
empty when the facade check targets are read by make, they end up with no
prerequisites at all, and the targets fail.
* [builds] Make the tools build use mono's packaged logic instead of our own.
Make the 'tools64' build use mono's packaged build logic instead of our own.
This is the first step to consuming the BCL from the mono archive.
Also completely refactor the 'tools64' build by removing everything we don't
need and renaming it to 'bcl' (since that's more representative of what it
does).
* [apidiff] Unzip downloaded files into a temporary subdirectory.
Before we unzip, we remove the target directory. This is a bad idea if the
target directory is also used for other things: in particular it breaks
parallel make if some other target tries to write to the temporary directory.
Instead unzip downloaded files into a subdirectory exclusively used by those
unzipped files, which means we can remove at will before unzipping.
* [apidiff] Use mono-api-[info|html].exe from the mono archive.
* Bump for Xcode 10.2 final
* Bump macios-binaries so mlaunch works on 10.14.4
* [appkit] Update for Xcode 10.2 final
* [mps] Update for Xcode 10.2 final
* Bump maccore for swift5 runtime support on older macOS versions
* [AppKit] Ignore deprecated API
* [tests] Don't test QTMovie, it's broken (crashes).
QTKit is deprecated (and has been for 5 years), so just don't test QTMovie.
Fixes these crashes:
apitest:
***** DelegateAndDataSourceAllowsNull
Stacktrace:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) ObjCRuntime.Messaging.IntPtr_objc_msgSend (intptr,intptr) [0x0000a] in <e8e733c9728c43cba731719f096ad306>:0
at QTKit.QTMovie..ctor () [0x00018] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/QTKit/QTMovie.g.cs:330
at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) [0x0004f] in <3ad39e28642b49d2a535a565e6bf6837>:0
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Reflection.MonoCMethod.InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&) [0x00016] in <3ad39e28642b49d2a535a565e6bf6837>:0
at System.Reflection.MonoCMethod.InternalInvoke (object,object[],bool) [0x00005] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/MonoMethod.cs:667
at System.Reflection.MonoCMethod.DoInvoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) [0x0007a] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/MonoMethod.cs:657
at System.Reflection.MonoCMethod.Invoke (System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) [0x00000] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/MonoMethod.cs:689
at System.Reflection.ConstructorInfo.Invoke (object[]) [0x00000] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/ConstructorInfo.cs:62
at Xamarin.Mac.Tests.DelegateAndDataSourceTest.DelegateAndDataSourceAllowsNull () [0x00110] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/apitest/src/DelegateAndDataSourceTest.cs:65
at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) [0x0004f] in <3ad39e28642b49d2a535a565e6bf6837>:0
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&) [0x00016] in <3ad39e28642b49d2a535a565e6bf6837>:0
at System.Reflection.MonoMethod.Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) [0x0003b] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/MonoMethod.cs:305
at System.Reflection.MethodBase.Invoke (object,object[]) [0x00000] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/referencesource/mscorlib/system/reflection/methodbase.cs:229
at NUnit.Framework.Internal.Reflect/<>c__DisplayClass9_0.<InvokeMethod>b__0 () [0x00000] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/Internal/Reflect.cs:226
at GuiUnit.InvokerHelper.Invoke () [0x0000e] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/GuiUnit/InvokerHelper.cs:18
at Foundation.NSActionDispatcher.Apply () [0x00000] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/Foundation/NSAction.cs:62
at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) [0x0004f] in <3ad39e28642b49d2a535a565e6bf6837>:0
at <unknown> <0xffffffff>
at (wrapper managed-to-native) ObjCRuntime.Messaging.void_objc_msgSend (intptr,intptr) [0x0000a] in <e8e733c9728c43cba731719f096ad306>:0
at AppKit.NSApplication.Run () [0x00012] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/AppKit/NSApplication.g.cs:2253
at Xamarin.Mac.Tests.MainClass/NSRunLoopIntegration.RunMainLoop () [0x00001] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/common/mac/MacTestMain.cs:79
at GuiUnit.TestRunner.ExecuteWithListener (string[],NUnitLite.Runner.TcpWriter) [0x0036f] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/GuiUnit/TestRunner.cs:234
at GuiUnit.TestRunner.Execute (string[]) [0x00093] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/GuiUnit/TestRunner.cs:137
at GuiUnit.TestRunner.Main (string[]) [0x00001] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/GuiUnit/TestRunner.cs:71
at Xamarin.Mac.Tests.MainClass.RunTests (string[]) [0x000a9] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/common/mac/MacTestMain.cs:56
at Xamarin.Mac.Tests.MainClass.Main (string[]) [0x00007] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/common/mac/MacTestMain.cs:35
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) [0x00051] in <4c10f2ab239246ba9514b976defa64c7>:0
Native stacktrace:
0 apitest 0x000000010c40b388 mono_handle_native_crash + 264
1 apitest 0x000000010c388dd6 altstack_handle_and_restore + 70
2 CoreFoundation 0x00007fff3b6f260b CFStringGetCString + 43
3 QTKit 0x00007fff457b6542 __51-[QTKitServerController startUsingServerForObject:]_block_invoke + 1238
4 libdispatch.dylib 0x00007fff67b4e63d _dispatch_client_callout + 8
5 libdispatch.dylib 0x00007fff67b5a129 _dispatch_lane_barrier_sync_invoke_and_complete + 60
6 QTKit 0x00007fff457b5f7a -[QTKitServerController startUsingServerForObject:] + 179
7 QTKit 0x00007fff457ac602 -[QTMovie_QuickTime initWithError:forParent:] + 98
8 QTKit 0x00007fff456f55b9 -[QTMovie initWithError:] + 59
9 apitest 0x000000010c31fbe9 xamarin_dyn_objc_msgSend + 217
10 ??? 0x0000000112791d05 0x0 + 4604894469
11 apitest 0x000000010c41f659 mono_jit_runtime_invoke + 1433
12 apitest 0x000000010c51a4df mono_runtime_invoke_checked + 127
13 apitest 0x000000010c522e70 mono_runtime_try_invoke_array + 1856
14 apitest 0x000000010c4be091 ves_icall_InternalInvoke + 657
15 ??? 0x0000000111abe261 0x0 + 4591444577
16 ??? 0x0000000114249463 0x0 + 4632908899
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
1 failing types:
QTKit.QTMovie: Object reference not set to an instance of an object
introspection:
***** ApiCtorInitTest.DefaultCtorAllowed
Stacktrace:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) ObjCRuntime.Messaging.IntPtr_objc_msgSend (intptr,intptr) [0x0000a] in <e8e733c9728c43cba731719f096ad306>:0
at QTKit.QTMovie..ctor () [0x00018] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/QTKit/QTMovie.g.cs:330
at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) [0x0004f] in <3ad39e28642b49d2a535a565e6bf6837>:0
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Reflection.MonoCMethod.InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&) [0x00016] in <3ad39e28642b49d2a535a565e6bf6837>:0
at System.Reflection.MonoCMethod.InternalInvoke (object,object[],bool) [0x00005] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/MonoMethod.cs:667
at System.Reflection.MonoCMethod.DoInvoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) [0x0007a] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/MonoMethod.cs:657
at System.Reflection.MonoCMethod.Invoke (System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) [0x00000] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/MonoMethod.cs:689
at System.Reflection.ConstructorInfo.Invoke (object[]) [0x00000] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/ConstructorInfo.cs:62
at Introspection.ApiCtorInitTest.DefaultCtorAllowed () [0x000f0] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/introspection/ApiCtorInitTest.cs:267
at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) [0x0004f] in <3ad39e28642b49d2a535a565e6bf6837>:0
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&) [0x00016] in <3ad39e28642b49d2a535a565e6bf6837>:0
at System.Reflection.MonoMethod.Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) [0x0003b] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/corlib/System.Reflection/MonoMethod.cs:305
at System.Reflection.MethodBase.Invoke (object,object[]) [0x00000] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/mcs/class/referencesource/mscorlib/system/reflection/methodbase.cs:229
at NUnit.Framework.Internal.Reflect/<>c__DisplayClass9_0.<InvokeMethod>b__0 () [0x00000] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/Internal/Reflect.cs:226
at GuiUnit.InvokerHelper.Invoke () [0x0000e] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/GuiUnit/InvokerHelper.cs:18
at Foundation.NSActionDispatcher.Apply () [0x00000] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/Foundation/NSAction.cs:62
at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) [0x0004f] in <3ad39e28642b49d2a535a565e6bf6837>:0
at <unknown> <0xffffffff>
at (wrapper managed-to-native) ObjCRuntime.Messaging.void_objc_msgSend (intptr,intptr) [0x0000a] in <e8e733c9728c43cba731719f096ad306>:0
at AppKit.NSApplication.Run () [0x00012] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.4.0.70/src/Xamarin.Mac/AppKit/NSApplication.g.cs:2253
at Xamarin.Mac.Tests.MainClass/NSRunLoopIntegration.RunMainLoop () [0x00001] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/common/mac/MacTestMain.cs:79
at GuiUnit.TestRunner.ExecuteWithListener (string[],NUnitLite.Runner.TcpWriter) [0x0036f] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/GuiUnit/TestRunner.cs:234
at GuiUnit.TestRunner.Execute (string[]) [0x00093] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/GuiUnit/TestRunner.cs:137
at GuiUnit.TestRunner.Main (string[]) [0x00001] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/external/guiunit/src/framework/GuiUnit/TestRunner.cs:71
at Xamarin.Mac.Tests.MainClass.RunTests (string[]) [0x000a9] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/common/mac/MacTestMain.cs:56
at Xamarin.Mac.Tests.MainClass.Main (string[]) [0x00007] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/common/mac/MacTestMain.cs:35
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) [0x00051] in <83b8b910cba94191a35185713f274e89>:0
Native stacktrace:
0 introspection 0x0000000104e33388 mono_handle_native_crash + 264
1 introspection 0x0000000104db0dd6 altstack_handle_and_restore + 70
2 CoreFoundation 0x00007fff3b6f260b CFStringGetCString + 43
3 QTKit 0x00007fff457b6542 __51-[QTKitServerController startUsingServerForObject:]_block_invoke + 1238
4 libdispatch.dylib 0x00007fff67b4e63d _dispatch_client_callout + 8
5 libdispatch.dylib 0x00007fff67b5a129 _dispatch_lane_barrier_sync_invoke_and_complete + 60
6 QTKit 0x00007fff457b5f7a -[QTKitServerController startUsingServerForObject:] + 179
7 QTKit 0x00007fff457ac602 -[QTMovie_QuickTime initWithError:forParent:] + 98
8 QTKit 0x00007fff456f55b9 -[QTMovie initWithError:] + 59
9 introspection 0x0000000104d47be9 xamarin_dyn_objc_msgSend + 217
10 ??? 0x00000001073f6de5 0x0 + 4416564709
11 introspection 0x0000000104e47659 mono_jit_runtime_invoke + 1433
12 introspection 0x0000000104f424df mono_runtime_invoke_checked + 127
13 introspection 0x0000000104f4ae70 mono_runtime_try_invoke_array + 1856
14 introspection 0x0000000104ee6091 ves_icall_InternalInvoke + 657
15 ??? 0x00000001072bd011 0x0 + 4415279121
16 ??? 0x000000010c993d63 0x0 + 4506336611
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
[FAIL] Default constructor not allowed for QTKit.QTMovie : Object reference not set to an instance of an object
Instead download the assemblies (part of existing bundle.zip) of the
current release and generate the XML locally (no storage in github)
before doing the diff against the newer, just built, assemblies.
reference: https://github.com/xamarin/xamarin-macios/issues/4891
Even if we don't end up using those variable during a normal build (when
building from source), it can still be useful that commands like `make download`
continue to work.
It also fixes a make warning:
Making all in builds
Makefile:16: warning: overriding commands for target `downloads/'
Makefile:9: warning: ignoring old commands for target `downloads/'
* [xibuild] Add support for /verbose, and use it accordingly.
Also stop using xibuild when it's not needed.
* Use the same verbosity for xibuild as we do for xbuild/msbuild.
* [builds] Consume LLVM from mono's package.
* Fix mono sdk paths in makefile to be relative to the top.
* [builds] Make curl verbose if V=1.
* [builds] Improve llvm build targets.
* Fix dependencies so that 'make -j llvm' (and other variations of the same
target) work properly.
* Rename things a bit to make it clear there are 32-bit and 64-bit llvm
targets.
* [builds] Consume cross compilers from mono's package as well.
Compiling the cross compilers while using LLVM from mono's package becomes
complicated, so just go ahead and get the cross compilers from the mono
package as well.
* Make llvm rules symmetric between llvm32 and llvm64.
* xibuild: New wrapper tool to run msbuild or managed executables
MSBuild supports fallback paths for projects imported using
`$(MSBuildExtensionsPath)`, but these must be specified explicitly in
the app.config of the main executable. There was a PR to allow use of
properties for this in the app.config, but that was not accepted
upstream.
This is required for being able to:
1. build projects with msbuild against the in-tree XI/XM build output
2. and to run nunit tests against the same.
For this we introduce a new tool, `xibuild`, based on XA's `xabuild`.
This supports the fallback paths to be specified via the environment variable
`MSBuildExtensionsPathFallbackPathsOverride`[1].
It essentially operates in 3 modes:
1. `xibuild -c /path/to/foo.exe`
Generates /path/to/foo.exe.config with the fallback paths inserted into that.
2. `xibuild -- /v:diag /path/to/project.csproj`
Runs msbuild with the arguments after `--` with a custom app.config based on
`MSBuild.dll.config`, with the fallback paths correctly inserted.
This is in a temporary file and the original config file is not touched.
3. `xibuild -t -- /path/to/managed_tool.exe args`
Generates `/path/to/managed_tool.exe.config` based on `MSBuild.dll.config` with
the fallback paths inserted, and runs `managed_tool.exe` with the arguments.
The default is to overwrite the config file.
But there is also a switch to merge it with an existing config file.
--
1. Value of the environment variable $MSBuildExtensionsPathFallbackPathsOverride
is prepended to any existing list of search paths in `MSBuild.dll.config`, IOW,
it takes precedence. So, the order of lookup becomes:
- Value of the property `$(MSBuildExtensionsPath)`
- Value of the environment variable `$MSBuildExtensionsPathFallbackPathsOverride`
- /Library/Frameworks/Mono.framework/External/xbuild on macOS
* Integrate use of `xibuild` with the tests
Update all uses of `msbuild` and invocations of tools like nunit that
might depend on using the in-tree builds to use `xibuild`.
* xibuild: Move help descriptions to OptionSet itself.
* MIN_OSX_SDK_VERSION: the minimum macOS version we support for running macOS apps.
* MIN_OSX_VERSION_FOR_MAC: the minimum macOS version we support for running XM/XI themselves.
Change our build to make sure the above is respected, and in particular:
* The mac32 and mac64 builds must use MIN_OSX_SDK_VERSION.
* The runtime/ build must use MIN_OSX_SDK_VERSION.
* The tools64 build should use MIN_OSX_VERSION_FOR_MAC.
Also document a bit better the various version variables.
Using a system mono < 5.18 results in a TypeLoadException:
Could not resolve type with token 01000032 from typeref (expected class 'Mono.ISystemDependencyProvider' in assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089')
Unce upon a time we used a separate mono submodule for watchOS support, to make
development of watchOS support easier (we referenced mono/master, to avoid
backporting fixes for watchOS support through various release branches in
mono).
This only worked until our watchOS support became stable, since then we had to
start using a stable version of mono for watchOS support.
This means that our build support for using a separate mono clone for watchOS
support is no longer needed; and in any case it's broken because of build
changes done later.
* Bump to mono:2018-06
* Bump mono
* Updates compression to work with the public span
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Bump Mono
* [runtime] always use `mono_jit_set_aot_mode` (#4491)
`mono_jit_set_aot_only` is deprecated and accidentally broke with
https://github.com/mono/mono/pull/7887
This should fix device tests with `mono-2018-06`
* Testing with Zoltan's patch
* Include libmono-system-native on Xamarin.Mac
* Bump Mono
Commit list for mono/mono:
* mono/mono@7bcda192a0 Bump llvm to release_60/fc854b8ec5873d294b80afa3e6cf6a88c5c48886. (#9786). (#9804)
* mono/mono@23e95ec7ad Apply F# portable pdb debug fix for pinvokes & bump (#9797)
* mono/mono@295f6d32af [2018-06] [MacOS] On Mac, use the copyfile API to copy files (#9696)
Diff: 7d5f4b6136...7bcda192a0
* Revert 4bacab3d5c, it doesn't fix the ios aot problems.
* Bump mono
* [tests] Adjust the MT0137 test for mcs change in behavior.
Starting with mono 5.16 mcs will now add assembly references when the assembly
is only used in attributes (this was already the case for csc in both 5.14 and
5.16, so it seems to be a compatibility change).
Adjust the MT0137 test accordingly.
* [msbuild] Fix parsing of json parser errors to handle trailing periods in the error message.
Fixes this test:
1) Test Failure : Xamarin.iOS.Tasks.Bug60536.TestACToolTaskCatchesJsonException
ColumnNumber
Expected: 2
But was: 0
* Bump mono
* [builds] Install the old llvm binaries into the LLVM36 directory and make the 32 bit builds use that.
* Bump mono
* Bump mono
* [jenkins] Don't give VSTS a fake branch. (#4667)
Something in VSTS changed, and now fake branch names don't work anymore.
So instead use real branch names (and for pull requests I've created a
'pull-request' branch we can use).
* Assembly.LoadFile accepts only absolute path
* [linker] Add new Facade (System.Threading.Tasks.Extensions).
Fixes these MTouch test failures:
1. Xamarin.Linker.SdkTest.iOS_Unified : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
2. Xamarin.Linker.SdkTest.tvOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
3. Xamarin.Linker.SdkTest.watchOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
* [mono-sdks] Necessary changes to unify the LLVM provisioning for both iOS and Android. (#4732)
* Bump Mono
* [mtouch] add mixed-mode support (#4751)
* [mtouch] add --interp-mixed option
When enabling this option, mtouch will AOT compile `mscorlib.dll`. At
runtime that means every method that wasn't AOT'd will be executed by
the runtime interpreter.
* [mtouch] Add support to --interpreter to list the assemblies to (not) interpret.
* [msbuild] Simplify interpreter code to use a single variable.
* Fix whitespace.
* [mtouch] Move mtouch-specific code to mtouch-specific file.
* [msbuild] An empty string is a valid value for 'Interpreter', so make it a non-required property.
* [mtouch] Add sanity check for aot-compiling interpreted assemblies.
* Bump Mono
* [linker] Updates SDKs facades list
* Bump mono
* [msbuild] Adds facades which might override default nuget version to framework list
The collision resolver task reads them from here https://github.com/dotnet/sdk/blob/master/src/Tasks/Common/ConflictResolution/FrameworkListReader.cs
* Bump to a VSfM version that can build XM Classic projects.
* Store the minimum mono version for Xamarin.Mac in one place only (Make.config) and bump it to 5.14. Fixes#4120.
I've verified that we fail at launch of running on 5.12, while 5.14 works fine
(to launch at least), so the minimum system mono version is _at least_ 5.14.
Fixes https://github.com/xamarin/xamarin-macios/issues/4120.
* [mmp] Load mono's version file instead of using pkg-config to get mono's version.
pkg-config will only get three parts of the version, while the version file
has all four parts.
This is important, since we're now verifying the four parts of the version
file, and without loading those four from the system, we'll fail builds like
this:
error MM0001: This version of Xamarin.Mac requires Mono 5.14.0.136 (the current Mono version is 5.14.0).
because the three part version's fourth number is assumed to be 0.
* Only verify mono runtime version when running with system/dynamic mono.
There should be no need to verify the mono runtime version when embedding mono:
* If it's a mono we're shipping, something very bad happened in our
build/package for it to be an invalid mono.
* If it's a system mono that's being embedded, then we verify in mmp at build
time.
In the first scenario (a mono we're shipping), the problem is that the mono
we've built does not report back the full version number (with four parts) [1],
which means we'll fail any check whose requirements are identical for the
first three parts, and non-zero for the last.
[1] The fourth part of the version number is created/calculated when packaging
mono, and we're not packaging it.
Only use Xcode 9.4 to build 32-bit mac binaries, we don't need it to build
anything else.
This way we can revert 7227d8c478, which is
causing issue #4582 (that commit changed variables containing SDK paths to be
SDK version agnostic, so that the variables could be used for all Xcode
versions - but that unfortunately triggers an obscure ld bug. If we don't need
those variables to refer to Xcode 9.4 paths, they can contain versions just
fine).
Fixes https://github.com/xamarin/xamarin-macios/issues/4582.
- Don't `XCODE_DEVELOPER_ROOT=$(XCODE94_DEVELOPER_ROOT)` this was causing everything to be built using 9.4.
- Build mac and ios targets with the right clang or xcode_dir based on if the target is 32 or 64 bit.
- Bump vsmac version
* Bump for Xcode 10 beta 3
Include a few changes to have green builds, e.g. it seems
`[GKAchievement init]` and `[GKAchievement initWithIdentifier:nil]`
are different now
```
[FAIL] Default constructor not allowed for GameKit.GKAchievement : Objective-C exception thrown. Name: NSInvalidArgumentException Reason: -[GKAchievement identifier]: unrecognized selector sent to instance 0x6000004a48d0
[FAIL] iOSApiCtorInitTest.ApiCtorInitTest.DefaultCtorAllowed : 1 potential errors found in 1426 default ctor validated:
```
* [xtro] Fix EventKit
* [tests] Make intro tests green in macOS Mojave Beta 3
* [tests] Make xtro happy
Add support for building on internal Jenkins.
Jenkins has been configured to build every branch on xamarin/xamarin-macios that contains a `jenkins/Jenkinsfile`, which means it will start working as soon as this PR is merged.
Results will be posted as statuses on each commit, which can be viewed using the url `https://github.com/xamarin/xamarin-macios/commits/<branch>`:
![screenshot 2018-06-01 11 12 57](https://user-images.githubusercontent.com/249268/40832932-c3b05eb0-658c-11e8-9670-8de5fcc23407.png)
* The `continuous-integration/jenkins/branch` status links to the jenkins job.
* The other two are XI and XM packages (the `Jenkins-` prefix will be removed once we officially switch from Wrench to Jenkins).
More detailed information will be added as a comment to each commit, which can be seen by clicking on the commit and scrolling to the bottom (url of the format `https://github.com/xamarin/xamarin-macios/commit/<sha1>`)
![screenshot 2018-06-01 11 14 33](https://user-images.githubusercontent.com/249268/40833014-fd8772f4-658c-11e8-8a35-5df46bfb16c7.png)
Unfortunately GitHub does not display the commit statuses when viewing a single commit, so to view those statuses you'll have to view the list of commits (the `/commits/` url). Tip: it's possible to use `<sha1>` instead of `<branch>` (and vice versa for that matter) if you're interested in the statuses of a particular commit.
Pull requests will also be built (only from contributors with write access), but by default nothing will be done (the job will exit immediately, although a green check mark will still show up). Jenkins will **not** add a comment in the pull request in this case.
However, if the label `build-package` [1] is set for a pull request, the internal jenkins job will run (it will do everything except the local xharness test run: this includes creating and publishing packages, creating various diffs, run tests on older macOS versions, test docs, etc). A detailed comment will also be added to the pull request (see below for multiple examples), which means that there will be two Jenkins comments: one for the public Jenkins which builds every PR, and one for the internal Jenkins [2].
[1] I don't quite like the name of the label, because it doesn't get even close to explain all that will actually happen, but `run-on-internal-jenkins-and-create-package` is a bit too long IMHO... Also it's non-obvious that this is the label to apply if the reason for executing on the internal jenkins is some other reason (for instance to test a maccore bump). Other ideas:
* `run-internal-jenkins`: doesn't make it obvious that a package will be created (which is probably the most common reason to want to run on internal jenkins)
* We could have multiple labels that mean the same thing: `build-package`, `internal-build`, `run-internal-jenkins`, etc, but it's redundant and I don't quite like it either.
* Any other ideas?
[2] I'm noticing now that these two look quite similar and this might end up confusing (the main difference is that the comment from the public jenkins will say **Build success/failure** and **Build comment file:** at the top. If something goes wrong the failure will also show up differently). Should this be made clearer?
* Bump to use Xcode 10 beta 1
* Update Versions.plist
* Add a dependency on Xcode 9.4.
* [msbuild] Fix build with Xcode 10 beta 1. (#4182)
Many years ago (in Xcode 7 according to code comment)
Developer/Platforms/iPhoneOS.platform/Developer/usr disappeared, and we coped
by looking at Developer/usr instead (and also the subsequent code to locate
the bin directory was based on the location of the usr directory).
Developer/Platforms/iPhoneOS.platform/Developer/usr reappeared in Xcode 10
beta 1, but it seems useless (for one it doesn't contain a bin directory), so
in order to try to keep things sane don't look for this directory in Xcode 10
and instead go directly for Developer/usr (which is what we've been using as
the usr directory for years anyway).
Fixes this problem when building apps with Xcode 10 beta 1:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(626,3): error : Could not locate SDK bin directory [/Users/rolf/Projects/TestApp/test-app.csproj]
* [runtime] Build 32-bit mac executables using Xcode 9.4.
* [mtouch] Work around broken tvOS headers in Xcode 10 beta 1.
* [mtouch] Work around build problem with Apple's simd headers in Objective-C++ mode.
* Use version-agnostic paths to sdk directories.
* [tests][xtro] Add todo files (from unclassified) and adjust ignore files to avoid errors
* [macos][security] Re-enable SSL[Get|Set]AlpnProtocols. Fixes#4001 (#4022)
* [macos][security] Re-enable SSL[Get}Set]AlpnProtocols. Fixes#4001
This was fixed in macOS 10.13.4
https://github.com/xamarin/xamarin-macios/issues/4001
* [tests][monotouch-tests] Disable a few test cases (one crasher, other failures). Causes to be verified later
* [xharness] Fix permission dialog suppression in Xcode 10.
* [xharness] Ignore 32-bit macOS tests by default.
* [tests] Execute mmp regression tests with Xcode 9.4 since many of them are 32-bit and needs porting to 64-bit.
* [mmptest] Ignore 32-bit XM tests if we don't have a 32-bit-capable Xcode.
* [registrar] Add workaround for broken headers in Xcode 10 beta 1 (radar 40824697).
* [mtouch] Restrict another workaround for an Xcode 10 beta 1 bug to a specific Xcode version to remove it asap.
* [tests] Fix some protocol changes (public or not) find by introspection tests
* [tests][intro] Fix DefaultCtorAllowed failures
* [Intents] Obsolete several Intents classes in watchOS.
Several existing Intents classes have been marked as unavailable in watchOS in
the headers in Xcode 10 beta 1, and corresponding tests are now failing.
So obsolete the managed wrapper types, and fix tests accordingly.
* Fix xtro wrt previous Ietents/intro changes
* [tests] Minor adjustments to mtouch tests to work with Xcode 10.
* [msbuild] Update tests to cope with additional files produced by the Core ML compiler.
* [msbuild] Xcode 10 doesn't support building watchOS 1 apps, so show a clear error message explaining it.
Also update tests accordingly.
* [coreimage] Stub new filters and exclude ?removed? ones from tests
* Update GameplayKit and SpriteKit NSSecureCoding _upgrade_ and fix other non-public cases (in tests)
* [tests] Ignore some GameKit selectors that don't respond anymore (but seems to be available, at least in header files)
* [tests] Fix intro 32bits testing for filters resutls
* [msbuild] Slightly change error message to be better English.
* Add support for building on Jenkins. (#4159)
Add support for building on internal Jenkins.
Jenkins has been configured to build every branch on xamarin/xamarin-macios that contains a `jenkins/Jenkinsfile`, which means it will start working as soon as this PR is merged.
Results will be posted as statuses on each commit, which can be viewed using the url `https://github.com/xamarin/xamarin-macios/commits/<branch>`:
![screenshot 2018-06-01 11 12 57](https://user-images.githubusercontent.com/249268/40832932-c3b05eb0-658c-11e8-9670-8de5fcc23407.png)
* The `continuous-integration/jenkins/branch` status links to the jenkins job.
* The other two are XI and XM packages (the `Jenkins-` prefix will be removed once we officially switch from Wrench to Jenkins).
More detailed information will be added as a comment to each commit, which can be seen by clicking on the commit and scrolling to the bottom (url of the format `https://github.com/xamarin/xamarin-macios/commit/<sha1>`)
![screenshot 2018-06-01 11 14 33](https://user-images.githubusercontent.com/249268/40833014-fd8772f4-658c-11e8-8a35-5df46bfb16c7.png)
Unfortunately GitHub does not display the commit statuses when viewing a single commit, so to view those statuses you'll have to view the list of commits (the `/commits/` url). Tip: it's possible to use `<sha1>` instead of `<branch>` (and vice versa for that matter) if you're interested in the statuses of a particular commit.
Pull requests will also be built (only from contributors with write access), but by default nothing will be done (the job will exit immediately, although a green check mark will still show up). Jenkins will **not** add a comment in the pull request in this case.
However, if the label `build-package` [1] is set for a pull request, the internal jenkins job will run (it will do everything except the local xharness test run: this includes creating and publishing packages, creating various diffs, run tests on older macOS versions, test docs, etc). A detailed comment will also be added to the pull request (see below for multiple examples), which means that there will be two Jenkins comments: one for the public Jenkins which builds every PR, and one for the internal Jenkins [2].
[1] I don't quite like the name of the label, because it doesn't get even close to explain all that will actually happen, but `run-on-internal-jenkins-and-create-package` is a bit too long IMHO... Also it's non-obvious that this is the label to apply if the reason for executing on the internal jenkins is some other reason (for instance to test a maccore bump). Other ideas:
* `run-internal-jenkins`: doesn't make it obvious that a package will be created (which is probably the most common reason to want to run on internal jenkins)
* We could have multiple labels that mean the same thing: `build-package`, `internal-build`, `run-internal-jenkins`, etc, but it's redundant and I don't quite like it either.
* Any other ideas?
[2] I'm noticing now that these two look quite similar and this might end up confusing (the main difference is that the comment from the public jenkins will say **Build success/failure** and **Build comment file:** at the top. If something goes wrong the failure will also show up differently). Should this be made clearer?
* Make the Jenkins packages official.
* [Jenkins] Create artifacts.json and set a GH status as 'Jenkins: Artifacts'.
* [jenkins] Include the url in artifacts.json
* [jenkins] Add sha256 checksum to artifacts.json as well.
* [Jenkins] Enable xamarin before provisioning so that we auto-provision Xcode.
* [jenkins] Fix passing flags to configure.
Quoting empty CONFIGURE_FLAGS ends up doing this:
./configure "" --disable-ios-device
and since configure parses arguments until it finds an empty argument, it
would stop parsing at the first argument, effectively not disabling the device
build.
So don't quote CONFIGURE_FLAGS when invoking configure. shellcheck doesn't
quite like this, but the better code is much more complex, and not really
needed, so just add an exception.