-
Notifications
You must be signed in to change notification settings - Fork 533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Xamarin.Android.Build.Tests] Ignore AOT tests if compiler is not available. #855
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ilable. This commit makes a number of changes to the unit tests to allow us to handle different behaviour between x-a and monodroid. Firstly we can now ignore AOT based tests if the compilers or runtime is not available. This means we can share the test inputs between repos. We also split out the Debugger Attribute test inputs into a ManifestTest.OSS.cs file to we can provide different inputs in monodroid. This is because there is a difference in behaviour between the two systems. In certain cases in monodroid we DO want a debug runtime/attribute where in x-a we never do. For exmaple in x-a having DebugSymbols = 'None', EmbedAssemblies=False and Optimize = False will result in the DebugAttribute not being added. This is correct behaviour for x-a because we ALWAYS embed assemblies regardless of the user setting. In monodroid hower that is incorrect. So we need seperate test cases. This commit also moves some of the logic to do with EmbedAssemblies into the Xamarin.Android.Common.targets. This is protected bu the `$(_XASupportsFastDev)` property. Again it means the logic is all in one place rather than being split up across .targets. This should make it easier to maintain.
jonpryor
reviewed
Sep 14, 2017
@@ -222,7 +222,9 @@ public void BuildAotApplication (string supportedAbis, bool enableLLVM, bool exp | |||
} | |||
using (var b = CreateApkBuilder (path)) { | |||
if (!b.CrossCompilerAvailable (supportedAbis)) | |||
Assert.Ignore ("Cross compiler was not available"); | |||
Assert.Ignore ($"Cross compiler for {supportedAbis} was not available"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps I'm missing something, but if we Assert.Ignore()
shouldn't we also immediately return
so that we don't continue execution? (Or does Assert.Ignore()
work by throwing an exception, thus exiting immediately? The documentation doesn't say.)
Assert.Ignore stops the run of the test immediately according to my tests.
…On 14 September 2017 at 13:05, Jonathan Pryor ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.
Build.Tests/BuildTest.cs
<#855 (comment)>
:
> @@ -222,7 +222,9 @@ public void BuildAotApplication (string supportedAbis, bool enableLLVM, bool exp
}
using (var b = CreateApkBuilder (path)) {
if (!b.CrossCompilerAvailable (supportedAbis))
- Assert.Ignore ("Cross compiler was not available");
+ Assert.Ignore ($"Cross compiler for {supportedAbis} was not available");
Perhaps I'm missing something, but if we Assert.Ignore() shouldn't we
also immediately return so that we don't continue execution? (Or does
Assert.Ignore() work by throwing an exception, thus exiting immediately? The
documentation <https://github.com/nunit/docs/wiki/Assert.Ignore> doesn't
say.)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#855 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAxeeSoHYDT7i6chEo4G5hdJvboy5Dzlks5siRakgaJpZM4PXT8g>
.
|
jonpryor
pushed a commit
that referenced
this pull request
Sep 19, 2017
This commit makes a number of changes to the unit tests to allow us to handle different behaviour between xamarin-android and monodroid. Firstly we can now ignore AOT based tests if the compilers or runtime is not available. This means we can share the test inputs between repos. We also split out the Debugger Attribute test inputs into a `ManifestTest.OSS.cs` file to we can provide different inputs in monodroid. This is because there is a difference in behaviour between the two systems. In certain cases in monodroid we *do* want a debug runtime/attribute where in xamarin-android we never do. For example in xamarin-android having: * `$(DebugSymbols)`=None * `$(EmbedAssembliesIntoApk)`=False * `$(Optimize)`=False will result in `//application/@android:debuggable` *not* being added. This is correct behavior in xamarin-android because we *always* embed assemblies regardless of the value of `$(EmbedAssembliesIntoApk)`. In monodroid however that is incorrect, so we need separate test cases. This commit also moves some of the logic to do with `$(EmbedAssembliesIntoApk)` into `Xamarin.Android.Common.targets`. This is protected by the `$(_XASupportsFastDev)` property. This means the logic is all in one place rather than being split up across `.targets`. This should make it easier to maintain.
jonpryor
added a commit
that referenced
this pull request
Jul 2, 2021
Fixes: dotnet/java-interop#854 Context: dotnet/java-interop#826 Changes: dotnet/java-interop@5e31647...48766c0 * dotnet/java-interop@48766c0d: Revert "[Xamarin.Android.Tools.Bytecode] hide nested types (#827)" (#855)
jonpryor
pushed a commit
that referenced
this pull request
Jul 21, 2021
Fixes: dotnet/java-interop#854 Changes: dotnet/installer@e8b3b6b...9c46371 % git diff --shortstat e8b3b6be...9c463710 103 files changed, 2301 insertions(+), 2757 deletions(-) Changes: dotnet/linker@a07cab7...460dd6d % git diff --shortstat a07cab7b...460dd6dd 84 files changed, 2403 insertions(+), 258 deletions(-) Changes: dotnet/runtime@02f70d0...96ce6b3 % git diff --shortstat 02f70d0b90...96ce6b3535 2586 files changed, 123677 insertions(+), 34433 deletions(-) Changes: dotnet/java-interop@a5ed891...4fb7c14 * dotnet/java-interop@4fb7c147: [build] set $(DisableImplicitNamespaceImports) by default (#859) * dotnet/java-interop@855ecfa3: [generator] Don't generate unexpected NRT types like `void?` (#856) * dotnet/java-interop@4a02bc32: Revert "[Xamarin.Android.Tools.Bytecode] hide nested types (#827)" (#855) * dotnet/java-interop@95c9b79d: [generator] Avoid 'error (…):' construct in diagnostic messages (#851) * dotnet/java-interop@7c4f7db0: [build] Bump to Mono with MSBuild 16.10 (#848) * dotnet/java-interop@0227cdae: [generator] Gracefully handle BindingGeneratorException. (#845) * dotnet/java-interop@ce1750fd: Add SECURITY.md (#846) Context: dotnet/runtime#55384 Context: dotnet/sdk#18639 Updates: * Microsoft.Dotnet.Sdk.Internal: from 6.0.100-preview.7.21327.2 to 6.0.100-rc.1.21369.3 * Microsoft.NET.ILLink.Tasks: from 6.0.100-preview.6.21322.1 to 6.0.100-preview.6.21366.2 * Microsoft.NETCore.App.Ref: from 6.0.0-preview.7.21326.8 to 6.0.0-rc.1.21368.1 dotnet/runtime#55384 broke how .NET 6 interacts with `AndroidClientHandler`. Fix this by introducing a new `Xamarin.Android.Net.AndroidMessageHandler` type for use on .NET 6, and update the .NET 6 `AndroidClientHandler` to delegate to `AndroidMessageHandler`. `AndroidMessageHandler` doesn't exist on Legacy. Update `.apkdesc` files: * `BuildReleaseArm64SimpleDotNet` is ~37KB smaller * `BuildReleaseArm64XFormsDotNet` is ~62KB larger. Update `tests/api-compatibility/api-compat-exclude-attributes.txt` so that `T:System.Runtime.CompilerServices.CompilerGeneratedAttribute` is ignored. `[CompilerGeneratedAttribute]` is emitted as part of C# 3 "auto-props": public T Property { get; set; } Converting this into a "real" property: T value; public T Property { get => value; set => this.value = value; } results in the `_CheckApiCompatibility` target complaining about an API break. We don't care; ignore `[CompilerGeneratedAttribute]`. Remove `$(SelfContained)` property: early on in .NET 5 (yes 5) development, the Xamarin.Android SDK needed to specify `$(SelfContained)` by default in order to produce `.apk` files. After we became a proper workload, setting the value became unnecessary. It also didn't actually do anything because dotnet/sdk overwrote the value. Starting in dotnet/sdk#18639, `Microsoft.NET.RuntimeIdentifierInference.targets` is now being imported *after* a workload, which meant that dotnet/sdk no longer overwrote our `$(SelfContained)` value, which broke things: error NETSDK1031: It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier. You must either specify a RuntimeIdentifier or set SelfContained to false. We can simply remove `$(SelfContained)` now, and rely on dotnet/sdk to set this value. Co-authored-by: Jonathan Peppers <[email protected]> Co-authored-by: Steve Pfister <[email protected]>
jonpryor
pushed a commit
that referenced
this pull request
Jul 21, 2021
Fixes: dotnet/java-interop#854 Changes: dotnet/installer@e8b3b6b...808795c % git diff --shortstat e8b3b6be...808795cc 102 files changed, 2218 insertions(+), 2674 deletions(-) Changes: dotnet/linker@a07cab7...9ecf5bd % git diff --shortstat a07cab7b...9ecf5bd2 81 files changed, 2122 insertions(+), 246 deletions(-) Changes: dotnet/runtime@02f70d0...8d3afa3 % git diff --shortstat 02f70d0b...8d3afa3a 2518 files changed, 122843 insertions(+), 33676 deletions(-) Changes: dotnet/java-interop@a5ed891...4fb7c14 * dotnet/java-interop@4fb7c147: [build] set $(DisableImplicitNamespaceImports) by default (#859) * dotnet/java-interop@855ecfa3: [generator] Don't generate unexpected NRT types like `void?` (#856) * dotnet/java-interop@4a02bc32: Revert "[Xamarin.Android.Tools.Bytecode] hide nested types (#827)" (#855) * dotnet/java-interop@95c9b79d: [generator] Avoid 'error (…):' construct in diagnostic messages (#851) * dotnet/java-interop@7c4f7db0: [build] Bump to Mono with MSBuild 16.10 (#848) * dotnet/java-interop@0227cdae: [generator] Gracefully handle BindingGeneratorException. (#845) * dotnet/java-interop@ce1750fd: Add SECURITY.md (#846) Context: dotnet/runtime#55384 Context: dotnet/sdk#18639 Updates: * Microsoft.Dotnet.Sdk.Internal: from 6.0.100-preview.7.21327.2 to 6.0.100-preview.7.21369.5 * Microsoft.NET.ILLink.Tasks: from 6.0.100-preview.6.21322.1 to 6.0.100-preview.6.21365.1 * Microsoft.NETCore.App.Ref: from 6.0.0-preview.7.21326.8 to 6.0.0-preview.7.21368.2 dotnet/runtime#55384 broke how .NET 6 interacts with `AndroidClientHandler`. Fix this by introducing a new `Xamarin.Android.Net.AndroidMessageHandler` type for use on .NET 6, and update the .NET 6 `AndroidClientHandler` to delegate to `AndroidMessageHandler`. `AndroidMessageHandler` doesn't exist on Legacy. Update `.apkdesc` files: * `BuildReleaseArm64SimpleDotNet` is ~37KB smaller * `BuildReleaseArm64XFormsDotNet` is ~62KB larger. Update `tests/api-compatibility/api-compat-exclude-attributes.txt` so that `T:System.Runtime.CompilerServices.CompilerGeneratedAttribute` is ignored. `[CompilerGeneratedAttribute]` is emitted as part of C# 3 "auto-props": public T Property { get; set; } Converting this into a "real" property: T value; public T Property { get => value; set => this.value = value; } results in the `_CheckApiCompatibility` target complaining about an API break. We don't care; ignore `[CompilerGeneratedAttribute]`. Remove `$(SelfContained)` property: early on in .NET 5 (yes 5) development, the Xamarin.Android SDK needed to specify `$(SelfContained)` by default in order to produce `.apk` files. After we became a proper workload, setting the value became unnecessary. It also didn't actually do anything because dotnet/sdk overwrote the value. Starting in dotnet/sdk#18639, `Microsoft.NET.RuntimeIdentifierInference.targets` is now being imported *after* a workload, which meant that dotnet/sdk no longer overwrote our `$(SelfContained)` value, which broke things: error NETSDK1031: It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier. You must either specify a RuntimeIdentifier or set SelfContained to false. We can simply remove `$(SelfContained)` now, and rely on dotnet/sdk to set this value. Co-authored-by: Jonathan Peppers <[email protected]> Co-authored-by: Steve Pfister <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit makes a number of changes to the unit tests to allow us
to handle different behaviour between x-a and monodroid.
Firstly we can now ignore AOT based tests if the compilers or
runtime is not available. This means we can share the test inputs
between repos.
We also split out the Debugger Attribute test inputs into a ManifestTest.OSS.cs
file to we can provide different inputs in monodroid. This is because
there is a difference in behaviour between the two systems. In certain
cases in monodroid we DO want a debug runtime/attribute where in x-a
we never do. For exmaple in x-a having DebugSymbols = 'None', EmbedAssemblies=False
and Optimize = False will result in the DebugAttribute not being
added. This is correct behaviour for x-a because we ALWAYS embed
assemblies regardless of the user setting.
In monodroid hower that is incorrect. So we need seperate test cases.
This commit also moves some of the logic to do with EmbedAssemblies into
the Xamarin.Android.Common.targets. This is protected bu the
$(_XASupportsFastDev)
property. Again it means the logic is all in one place rather than
being split up across .targets. This should make it easier to maintain.