-
Notifications
You must be signed in to change notification settings - Fork 552
[mono] PR tracking the 2017-04 bump. #551
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
Conversation
@kumpera, |
That's probably because 3e5c484 is kumpera/Java.Interop/3e5c484f, not xamarin/Java.Interop/3e5c484f. If you create a branch from xamarin/Java.Interop and not kumpera/Java.Interop, this will presumably work. Or, if you "fix" the ...or we accept dotnet/java-interop#141 and then you can bump "normally." That Cecil bump looks "big." |
build |
c2a6cb4
to
e2f8f20
Compare
The old project for System.Drawing.Primitives was removed in favor of building the assembly with the existing logic in Mono.
# Conflicts: # build-tools/dependencies/dependencies.projitems # external/mono # src/System.Drawing.Primitives/System.Drawing.Primitives.targets # src/netstandard/netstandard.targets
Can we rebuild this? The CI build is failing with
|
build |
Could somebody look at this? |
@directhex: wrt @radical's question, is there some preferred mechanism to convince "the" Linux builder to install Mono 5.2 instead of (presumably) the current 4.9? I think we're going to need some mechanism of specifying which mono version to install, and I'm not sure what that should be. Could we e.g. add a Linux lane specific to this PR so that it installs the correct Mono version until merged on master? Something else? |
@jonpryor the preferred mechanism crumbles a bit when the request is for a version which isn't in alpha yet. I already added a mechanism to make it possible to add one-off builds as repositories, what I don't have is any package-related one-off builds of the 5.2 branch. I'll see what I can do. |
We ignore linux CI results when testing newer mono. Looks like everything is good now! |
I was looking at this because of https://bugzilla.xamarin.com/show_bug.cgi?id=55287 . Can the bug be closed now? |
Is Mono master (5.3.x) usable, or does it need to be 5.2? |
@directhex I think 5.4 would do it, but it's not strictly needed. I think this PR is ready for merging as is once the linker conflict is resolved. |
@directhex ugg, forget that, we'll need those packages to move this forward. |
The current plans to address the linker conflict are for @radekdoulik to remove |
A |
@directhex: Do what you did with PR #445: when the Jenkins+Linux instance is started, have it install the This should be done for the |
build |
OK, it's not finished building, but it's actually starting now, so my work here is done. |
- instead use mono's one in mono/external/linker
@marek-safar we are missing this commit here for XA: dotnet/linker@6e4e50c would you mind if I create a new branch on linker named mono-2017-04, cheery-pick the commit and let mono/2017-04 use the linker branch? |
It's another moved assembly.
- the emulators are now timeouting on wrench and it looks like this might fix it. I have tested it on my rodos-playground branch and wrench run the emulators fine there. fingers crossed :-) (cherry-picked from xamarin/monodroid@62278e4)
@@ -343,6 +343,12 @@ | |||
<Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker.Steps\MarkStep.cs"> | |||
<Link>Linker\Mono.Linker.Steps\MarkStep.cs</Link> | |||
</Compile> | |||
<Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker\LoadException.cs"> |
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.
This is currently breaking the build:
13:27:12 CSC : error CS2001: Source file '/Users/builder/jenkins/workspace/xamarin-android-msbuild-pr-builder/external/linker/linker/Mono.Linker/LoadException.cs' could not be found.
<Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker\LoadException.cs"> | ||
<Link>Linker\Mono.Linker\LoadException.cs</Link> | ||
</Compile> | ||
<Compile Include="$(LinkerSourceFullPath)\linker\Mono.Linker\MarkException.cs"> |
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.
...ditto MarkException.cs
Bump to mono/2017-04/24c4d616.
Context: https://github.com/xamarin/QualityAssurance/pull/3478 Context: https://xqa.blob.core.windows.net/gist/report-60e42aa322884cedbc8908438cc75dad.txt Changes: dotnet/java-interop@d61b329...476597b * dotnet/java-interop@476597b: [tests] Convert to Unix style line endings (#551) One of the Java.Interop unit tests was implicitly depending on line ending consistency, and would fail if the project was built on Windows after commit 130905e, which began executing those tests: 23) Java.InteropTests.JniValueMarshaler_SByte_ContractTests.JniValueMarshalerContractTests`1.CreateReturnValueFromManagedExpression (Java.Interop-Tests) Expected string length 112 but was 100. Strings differ at index 1. Expected: "{\r\n\tJniRuntime __jvm;\r\n\tsbyte __value;\r\n\r\n\ttry\r\n\t{\r\n\t\treturn ..." But was: "{\n\tJniRuntime __jvm;\n\tsbyte __value;\n\n\ttry\n\t{\n\t\treturn __valu..." -------------^ dotnet/java-interop@476597b normalizes line endings, fixing this failure.
No description provided.