-
Notifications
You must be signed in to change notification settings - Fork 537
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Bump to xamarin/Java.Interop/master@56c92c70 (#4376)
Changes: dotnet/java-interop@1a086ff...56c92c7 * dotnet/java-interop@56c92c7: [build] Remove cecil submodule (#597) * dotnet/java-interop@3091274: [build] Provide a default $(Configuration) value (#612) * dotnet/java-interop@cf3e7c2: [generator] Don't process duplicate reference assemblies (#611) * dotnet/java-interop@f5fa462: [jnienv-gen] Convert to SDK-style (#608) Of particular note is [dotnet/java-interop@56c92c7][0], which replaces the `mono/cecil` submodule within Java.Interop with the [`Mono.Cecil` NuGet package][1] in an effort to simplify the Java.Interop build system. This simplifies the Java.Interop repo, and we *thought* that since xamarin-android *doesn't even use* Java.Interop's cecil submodule-built `Mono.Cecil.dll` -- instead the `Mono.Cecil.dll` from the "mono archive" is "renamed" to `Xamarin.Android.Cecil.dll` during `make prepare` (0c9f83b) -- surely this would be a simple change. The removal of the cecil submodule also required changing `ThirdPartyNotice.txt` generation so that the LICENSE for Cecil was obtained from the mono archive instead of from Java.Interop. Unfortunately, the integration was a tad more complicated than anticipated. With the ongoing adoption of MSBuild multi-targeting and builds against the `netcoreapp3.1` target framework -- commit e2854ee and numerous commits in Java.Interop -- we encountered a problem with MSBuild semantics: If two `$(TargetFramework)` builds share the same output directory, the `IncrementalClean` target will *remove files created by previous builds*, e.g. when e.g. `Java.Interop/tools/generator.csproj` builds the `netcoreapp3.1` framework, it will *delete* the `generator.exe` built by the `net472` framework, which results in subsequent build breaks. The only path to sanity is to *ensure* that different `$(TargetFramework)` builds have *completely separate* `$(OutputPath)` values. The "normal" approach to doing this is for `$(OutputPath)` to end with `$(TargetFramework)`, which is the case when `$(AppendTargetFrameworkToOutputPath)`=True (the default). Unfortunately in xamarin-android we don't want `$(OutputPath)` to end with `$(TargetFramework)`; we want the build tree structure to mirror the installation directory structure, which -- at present -- doesn't mention `$(TargetFramework)` at all. The solution here is to use "non-overlapping" directories. For example, in e2854ee there are "two" `$(OutputPath)` values: * `MonoAndroid10.0`: `bin/Debug/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v10.0/Mono.Android.dll` * `netcoreapp3.1`: `bin/Debug/lib/xamarin.android/xbuild-frameworks/Xamarin.Android.App/netcoreapp3.1/Mono.Android.dll` The same "non-overlapping directories" strategy needs to be extended to *all* multi-targeted projects from Java.Interop, *including* dependencies. Dependencies such as `Xamarin.Android.Cecil.dll`. Define a new `$(UtilityOutputFullPathCoreApps)` MSBuild property so that Java.Interop "utility" project builds, when building for the `netcoreapp3.1` framework, use a *different* `Xamarin.Android.Cecil.dll` than is used with the `net472`-related builds. Update `xaprepare` to *create* this new `netcoreapp3.1`-correlated `Xamarin.Android.Cecil.dll`. It's the same file, just in a different directory, to prevent "accidental" deletes by `IncrementalClean`. Even with all that, MSBuild still had other ideas. In particular, MSBuild wasn't particularly happy about our attempt to use the `$(UtilityOutputFullPath)` property to "switch" between using a `@(PackageReference)` to the Mono.Cecil NuGet package vs. using a `@(Reference)` to the `Xamarin.Android.Cecil.dll` assembly, because MSBuild *caches* this information somewhere within `obj` directories. To get MSBuild to re-evaluate it's assembly reference choices, we must instead replace `msbuild` with `msbuild /restore`. Which still isn't enough, because some of our MSBuild invocations are via the `<MSBuild/>` task, within `msbuild`. To get *that* working, we need to explicitly invoke the `Restore` target through a *separate* `<MSBuild/>` task invocation. You ***CANNOT*** use `<MSBuild Targets="Restore;Build" />`, as "obvious" as that may be, because it [doesn't work reliably][2]. ([Yet.][3]) [0]: dotnet/java-interop@56c92c7 [1]: https://www.nuget.org/packages/Mono.Cecil/0.11.2 [2]: dotnet/msbuild#3000 (comment) [3]: dotnet/msbuild#2811
- Loading branch information
Showing
13 changed files
with
32 additions
and
31 deletions.
There are no files selected for viewing
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
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
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
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
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
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
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
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
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
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
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
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
Submodule Java.Interop
updated
from 1a086f to 56c92c