This task ends up setting as env variable the Xamarin Sdk root directory on the Mac, but when building from Windows it was setting the Windows path, so instead we need to override it with the proper value on macOS.
This should not change the original behavior when building from macOS.
The test was merge with the xammac_tests in commit
93bbfe7a86
but we did not have the tests running to know.
This should fix some of the failures we have in older macs.
- Make git ignore the generated `report.md`
- Fix `.aotdata` reported total size in reports (was always 0)
- Add option to strip the dotnet app bundle (until [1]) so it's easier to compare with _oldnet_ sizes.
[1] https://github.com/xamarin/xamarin-macios/issues/11445
* [dotnet] Ship the buildinfo file.
* [msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes#10827.
We do this by setting the _XamarinSdkRoot variable in our .NET logic, which
our existing shared build logic reads, passes to the DetectSdkLocations task,
and then sets our override environment variable
(MD_MTOUCH_SDK_ROOT/XAMMAC_FRAMEWORK_PATH) to the install location, so that
existing code (which honors the override variable) continues to work as-is.
Fixes https://github.com/xamarin/xamarin-macios/issues/10827.
Create two pipelines that will be triggered when a new build is
completed and contains tests results. There are some important details:
1. pipeline triggers have to specify all branches or a subset. We use
tags to trigger for PRs.
2. Tags are and, not or, so we need to pipelines (lame lame).
Due to 2. we add a new tag to identify ci builds.
Do not publish the nugets that have been created in a PR build. The
build results can be accessed from the comment once completed. This way
we make sure that next builds do not have conflicts when publishing the
nugets.
This makes it easier to test localized strings used in mtouch, since we don't have
to replicate the build for all the resources.
This required a few changes to avoid including code in the mtouch tests that already
exists in the mtouch executable.
Also rename the mtouch test project to mtouchtests.csproj.
This way the test project can reference the actual mtouch.csproj without
causing conflicts due to having two projects with the same name.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
There's no general way to set a pending managed exception in CoreCLR (the
current plan is to support setting a pending managed exception for the
objc_msgSend family of functions). This means that the way we've implemented
custom wrappers that can handle Objective-C exceptions won't work, because
those wrappers currently tries to set a pending managed exception (which Mono
throws upon returning from the corresponding native wrapper function).
So rewrite this a bit: these custom wrappers now return a GCHandle with the
managed exception as an out parameter, and the calling managed code throws
that exception instead.
This also required adjusting a few API definitions to match how their wrapper
functions are defined.
* [runtime] Call into managed code to handle runtime exceptions.
This makes things easier for CoreCLR.
There should be no significant performance hits; this code path is
exceptional, and exceptions are already very heavy-weight anyways.
* Update to use xamarin_free instead of mono_free as per review.
* Port more to managed code.
Create a new parameter that can be used to decide if we build or not the
dotnet parts of the project. If we do not, we make sure that we do not
have any errors in all the other steps.
A wrong implementation of a redirect was added and returns a 403 and not
a 302 resulting in an error. Update to the final destination of the
redirect and be happy.
fixes https://github.com/xamarin/maccore/issues/2432
We have to consider (setup and process) `libSystem.Globalization.Native`
in order not to remove the required symbols when stripping the native
executable.
Ignore `libSystem.Globalization.Native` for dotnet / catalyst
ref: https://github.com/xamarin/xamarin-macios/issues/11392
Build failures will now include things like this for quiet builds:
Tool xcrun execution finished (exit code = 1).
Undefined symbols for architecture x86_64:
"_GlobalizationNative_LoadICUData", referenced from:
-u command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Ship all files published by 'dotnet publish' for bgen, not only files prefixed
by 'bgen*'. This way we ship Mono.Options.dll too (and we won't crash at
launch trying to look for it).
Fixes https://github.com/xamarin/xamarin-macios/issues/11269.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Use the jenkins script as a base to get the PAI & generator from stable
diff back to the CI. Comment is not perfect, but does provide the
required information. The comment can be improve in a later commit since
this is getting too large.
This seems to be required when running monotouch-test with lldb (!) - no idea
why it doesn't fail otherwise.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Remove 1 array allocation per print statement.
* Remove 2 string concatenations per print statement.
* Don't indent empty lines.
For the generated code for watchOS, this is the difference (time-wise I wasn't
able to measure anything significant, although the memory savings are
significant):
Before:
Allocation summary
Bytes Count Average Type name
535.485.544 7.115.025 75 System.String
145.340.480 2.270.945 64 IKVM.Reflection.CustomAttributeData
110.149.624 1.238.394 88 System.Char[]
...
Total memory allocated: 1.793.323.536 bytes in 28.827.325d objects
After:
Allocation summary
Bytes Count Average Type name
494.592.328 6.624.441 74 System.String
145.340.480 2.270.945 64 IKVM.Reflection.CustomAttributeData
99.345.984 968.303 102 System.Char[]
...
Total memory allocated: 1.741.626.784 bytes in 28.066.650d objects
Difference:
Allocation summary
Bytes Count Average Type name
-40.893.216 -490.584 -1 System.String
0 0 64 IKVM.Reflection.CustomAttributeData
-10.803.640 -270.091 +14 System.Char[]
...
Total memory allocated: -51.696.752 bytes in -760.675 objects
This was measured by executing the following in an already built working copy:
/Library/Frameworks/Mono.framework/Versions/Current/bin/mono --profile=log:nocalls,alloc --debug build/common/bgen.exe @build/watchos.rsp
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>