-
Notifications
You must be signed in to change notification settings - Fork 537
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
[build] Add make jenkins
target.
#116
Conversation
@@ -0,0 +1,62 @@ | |||
# $(ALL_API_LEVELS) and $(ALL_FRAMEWORKS) must be kept in sync w/ each other | |||
ALL_API_LEVELS = 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
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.
Do we really need anything below 9 here?
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.
Yes, for the same reason that $(ALL_FRAMEWORKS)
has a bunch of -
values.
That reason being that $(FRAMEWORKS)
and others use the $(word n,text) function, and $(word) requires 1-based values. If $(ALL_API_LEVELS)
doesn't have 1..9, then $(word 10, $(ALL_API_LEVELS)
won't be 10, which means $(word 10, $(ALL_FRAMEWORKS)
won't be v2.3
, which greatly hampers the ability, within make, to associate those values.
This might be a sign that this associate shouldn't be done within Make; perhaps it should be done within Mono.Android.targets
? I'm not certain how that would work either.
25481fb
to
9685d79
Compare
The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
@jonpryor @grendello looks ok to me. |
It looks good to me, except for one thing - unless I'm mistaken, the change to |
@grendello: That is correct. Should that be fixed before merging this PR? Or done separately? (I'd really like to get this in so that @duncanmak can start using it...) |
I think separately is fine |
Related: https://bugzilla.xamarin.com/show_bug.cgi?id=46344#c12 class-parse has brought another problem; it generates fields and methods that are compiler-generated and should not have been written to XML in the first place. class-parse has no idea on how to deal with them, so kill them in api-xml-adjuster instead.
Xamarin.Android v11.3.0 will be shipped as part of Visual Studio 2019 16.10 Preview 3 and subsequent releases. Changes: mono/debugger-libs@8bf09ce...08268b7 * mono/debugger-libs@08268b7: Add Module.ApplyChanges (#342) * mono/debugger-libs@1b5a55a: Fix assembly version after converting projects to SDK style Changes: dotnet/java-interop@f9faaab...f39db25 * dotnet/java-interop@f39db25c: Branching for d16-10. * dotnet/java-interop@f4e68b5b: [generator] Separate metadata fixup step from parsing step. (#822) Changes: xamarin/monodroid@76c04cd...69e9111 * xamarin/monodroid@69e911139: Branching for d16-10. * xamarin/monodroid@9f9ee378c: [tools/msbuild] Missing translations for XA0135 (#1198) Changes: dotnet/android-tools@d92fc3e...c5732a0 * dotnet/android-tools@c5732a0: [Xamarin.Android.Tools.AndroidSdk] Support Microsoft Dist JDK (#117) * dotnet/android-tools@52ef989: [Xamarin.Android.Tools.AndroidSdk] Fix CS0168 warning (#116)
Xamarin.Android v11.3.0 will be shipped as part of Visual Studio 2019 16.10 Preview 3 and subsequent releases. Changes: mono/debugger-libs@8bf09ce...08268b7 * mono/debugger-libs@08268b7: Add Module.ApplyChanges (#342) * mono/debugger-libs@1b5a55a: Fix assembly version after converting projects to SDK style Changes: dotnet/java-interop@f9faaab...f39db25 * dotnet/java-interop@f39db25c: Branching for d16-10. * dotnet/java-interop@f4e68b5b: [generator] Separate metadata fixup step from parsing step. (#822) Changes: xamarin/monodroid@76c04cd...69e9111 * xamarin/monodroid@69e911139: Branching for d16-10. * xamarin/monodroid@9f9ee378c: [tools/msbuild] Missing translations for XA0135 (#1198) Changes: dotnet/android-tools@d92fc3e...c5732a0 * dotnet/android-tools@c5732a0: [Xamarin.Android.Tools.AndroidSdk] Support Microsoft Dist JDK (#117) * dotnet/android-tools@52ef989: [Xamarin.Android.Tools.AndroidSdk] Fix CS0168 warning (#116)
(Commercial) Xamarin.Android v11.3 is being tracked in the [xamarin-android/d16-10][0] branch, which was branched from commit eac74eb. Bump `$(ProductVersion)` to 11.3.99 to track development progress of the *next* version of Xamarin.Android. Additionally, bump various submodules to their "main" equivalents to mirror the d16-10 branch commit 496a43a, and update `.gitmodules` so that the correct branch name is used: Changes: mono/debugger-libs@8bf09ce...08268b7 * mono/debugger-libs@08268b7: Add Module.ApplyChanges (dotnet#342) * mono/debugger-libs@1b5a55a: Fix assembly version after converting projects to SDK style Changes: mono/opentk@933939d...50128f7 * mono/opentk@50128f7a: Create Xamarin.Legacy.OpenTK Nuget Package (dotnet#28) * mono/opentk@72f4b085: Merge pull request dotnet#26 from dellis1972/ci * mono/opentk@b8fd3d2f: Fix Path issue * mono/opentk@62fd3b17: Clean up * mono/opentk@3a1a53c7: Add missing files. Update .gitignore * mono/opentk@e657cf71: Build with dotnet * mono/opentk@6e9a6160: Switch to using Xamarin.Legacy.Sdk * mono/opentk@a46a0668: rework * mono/opentk@cdae43e0: Initial Commit for Building Android Changes: dotnet/android-tools@d92fc3e...c5732a0 * dotnet/android-tools@c5732a0: [Xamarin.Android.Tools.AndroidSdk] Support Microsoft Dist JDK (dotnet#117) * dotnet/android-tools@52ef989: [Xamarin.Android.Tools.AndroidSdk] Fix CS0168 warning (dotnet#116) [0]: https://github.com/xamarin/xamarin-android/commits/d16-10
(Commercial) Xamarin.Android v11.3 is being tracked in the [xamarin-android/d16-10][0] branch, which was branched from commit eac74eb. Bump `$(ProductVersion)` to 11.3.99 to track development progress of the *next* version of Xamarin.Android. Additionally, bump various submodules to their "main" equivalents to mirror the d16-10 branch commit 496a43a, and update `.gitmodules` so that the correct branch name is used: Changes: mono/debugger-libs@8bf09ce...08268b7 * mono/debugger-libs@08268b7: Add Module.ApplyChanges (#342) * mono/debugger-libs@1b5a55a: Fix assembly version after converting projects to SDK style Changes: mono/opentk@933939d...50128f7 * mono/opentk@50128f7a: Create Xamarin.Legacy.OpenTK Nuget Package (#28) * mono/opentk@72f4b085: Merge pull request #26 from dellis1972/ci * mono/opentk@b8fd3d2f: Fix Path issue * mono/opentk@62fd3b17: Clean up * mono/opentk@3a1a53c7: Add missing files. Update .gitignore * mono/opentk@e657cf71: Build with dotnet * mono/opentk@6e9a6160: Switch to using Xamarin.Legacy.Sdk * mono/opentk@a46a0668: rework * mono/opentk@cdae43e0: Initial Commit for Building Android Changes: dotnet/android-tools@d92fc3e...c5732a0 * dotnet/android-tools@c5732a0: [Xamarin.Android.Tools.AndroidSdk] Support Microsoft Dist JDK (#117) * dotnet/android-tools@52ef989: [Xamarin.Android.Tools.AndroidSdk] Fix CS0168 warning (#116) [0]: https://github.com/xamarin/xamarin-android/commits/d16-10
(Commercial) Xamarin.Android v11.3 is being tracked in the [xamarin-android/d16-10][0] branch, which was branched from commit eac74eb. Bump `$(ProductVersion)` to 11.3.99 to track development progress of the *next* version of Xamarin.Android. Additionally, bump various submodules to their "main" equivalents to mirror the d16-10 branch commit 496a43a, and update `.gitmodules` so that the correct branch name is used: Changes: mono/debugger-libs@8bf09ce...08268b7 * mono/debugger-libs@08268b7: Add Module.ApplyChanges (#342) * mono/debugger-libs@1b5a55a: Fix assembly version after converting projects to SDK style Changes: mono/opentk@933939d...50128f7 * mono/opentk@50128f7a: Create Xamarin.Legacy.OpenTK Nuget Package (#28) * mono/opentk@72f4b085: Merge pull request #26 from dellis1972/ci * mono/opentk@b8fd3d2f: Fix Path issue * mono/opentk@62fd3b17: Clean up * mono/opentk@3a1a53c7: Add missing files. Update .gitignore * mono/opentk@e657cf71: Build with dotnet * mono/opentk@6e9a6160: Switch to using Xamarin.Legacy.Sdk * mono/opentk@a46a0668: rework * mono/opentk@cdae43e0: Initial Commit for Building Android Changes: dotnet/android-tools@d92fc3e...c5732a0 * dotnet/android-tools@c5732a0: [Xamarin.Android.Tools.AndroidSdk] Support Microsoft Dist JDK (#117) * dotnet/android-tools@52ef989: [Xamarin.Android.Tools.AndroidSdk] Fix CS0168 warning (#116) [0]: https://github.com/xamarin/xamarin-android/commits/d16-10
The
make jenkins
^0 target is for use by Continuous Integrationmachines, to build everything ^1.
This is expected to take an eternity. Think hours.
Of particular note is that the above "everything" includes
Release configuration builds of everything, which is something that
didn't actually work before. (Oops.)
Bump Java.Interop so that it supports building the Release
configuration, update Xamarin.Android.sln so that all required
projects are part of the Release configuration, and update
Xamarin.Android.Build.Tasks.csproj so that
JCW_ONLY_TYPE_NAMES
isn'tdefined, as this was preventing compilation.
Fix strip(1) use:
mono-runtimes.targets
was trying to usestrip -S
on macOS, but the value of%(_MonoRuntime.Strip)
wasquoted, and thus attempted to execute
"strip -S" ...
, which failed.Move the
-S
into a new%(_MonoRuntime.StripFlags)
value.Fixup
mono-runtimes.targets
and related files so that$(MonoSourceFullPath)
is used instead of a relative path. This helpsalleviate the "mental math" of determining the relative path to the
Mono checkout. Plus, the Mono checkout is supposed to be overridable,
e.g. commit d205cab, and using
$(MonoSourceFullPath)
supports that.Download and install
android.jar
for all supported API levels.Fix the
Mono.Android.csproj
build so thatMono.Android.dll
isstored in a per-API-level intermediate directory. Otherwise, if e.g.
API-10 is built after API-23, the API-23 version will be installed,
but the JCW build will fail. Additionally, API-24 requires using
javac -source 1.8 -target 1.8
, not 1.6.Fix
Mono.Android/metadata
to use the correctmerge.SourceFile
filename of
Profiles/api-24.xml.in
. Without that fix, API-24 won'tbuild because
NumericShaper.GetContextualShaper()
is emitted twice,and the C# compiler doesn't like that.
Disable use of
-lz
when building for Windows. Windows doesn'tcontain a
Z.DLL
to link against.