Uh oh!
There was an error while loading. Please reload this page.
Bump to xamarin/Java.Interop/master@56c92c70 - #4376
Merged
Merged
Conversation
jonpryor
commented
Mar 10, 2020
ContributorAuthor
Doh, forgot to make this a Draft! |
jonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
from
March 10, 2020 02:52
b022fd2 to
1a55380Comparegrendello
approved these changes
Mar 10, 2020
jonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
2 times, most recently
from
March 10, 2020 16:19
d9e3261 to
71c17f8Comparejonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
from
March 18, 2020 19:15
71c17f8 to
4c0580eComparejonpryor
commented
Mar 19, 2020
ContributorAuthor
Alas, it doesn't work; it fails to build: Current conjecture is that Furthermore, if I delete the |
jonpryor
commented
Mar 19, 2020
ContributorAuthor
It looks like using |
jonpryor added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Mar 19, 2020
***DO NOT MERGE*** Context: dotnet/java-interop#597 Just testing to see if dotnet/java-interop#597 works... Need to use `msbuild /restore` for all builds to allow `Java.Interop.Tools.Cecil` to build; see: dotnet#4376 (comment)
jonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
from
March 19, 2020 15:27
4c0580e to
a5a2a5dComparejonpryor added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Mar 19, 2020
***DO NOT MERGE*** Context: dotnet/java-interop#597 Just testing to see if dotnet/java-interop#597 works... Need to use `msbuild /restore` for all builds to allow `Java.Interop.Tools.Cecil` to build; see: dotnet#4376 (comment)
jonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
from
March 19, 2020 19:47
a5a2a5d to
b70579fComparejonpryor added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Mar 19, 2020
***DO NOT MERGE*** Context: dotnet/java-interop#597 Just testing to see if dotnet/java-interop#597 works... Need to use `msbuild /restore` for all builds to allow `Java.Interop.Tools.Cecil` to build; see: dotnet#4376 (comment) Note: `$(TargetFrameworks)` throws a wrench into things. If two `$(TargetFramework)` builds share the same output directory, the `IncrementalClean` target will *remove files created by previous builds*, e.g. when e.g. `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)`. The problem here is that xamarin-android is setup so that we mirror the installation directory, with e.g. `bin/Debug` being an "installation root", and that installation root *won't* (normally?) have *both* net472 and netcoreapp3.1 outputs for the "same" project. The "solution" is to use the new `$(UtilityOutputFullPathCoreApps)` property within Java.Interop to ensure that Java.Interop "utility" apps -- normally placed into `bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android` -- are *instead* placed into `bin/Debug-netcoreapp3.1` for netcoreapp3.1 builds. This ensure that things *actually build*. Locally. YMMV.
jonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
from
March 19, 2020 22:46
b70579f to
b39a585Comparejonpryor added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Mar 20, 2020
***DO NOT MERGE*** Context: dotnet/java-interop#597 Just testing to see if dotnet/java-interop#597 works... Need to use `msbuild /restore` for all builds to allow `Java.Interop.Tools.Cecil` to build; see: dotnet#4376 (comment) Note: `$(TargetFrameworks)` throws a wrench into things. If two `$(TargetFramework)` builds share the same output directory, the `IncrementalClean` target will *remove files created by previous builds*, e.g. when e.g. `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)`. The problem here is that xamarin-android is setup so that we mirror the installation directory, with e.g. `bin/Debug` being an "installation root", and that installation root *won't* (normally?) have *both* net472 and netcoreapp3.1 outputs for the "same" project. The "solution" is to use the new `$(UtilityOutputFullPathCoreApps)` property within Java.Interop to ensure that Java.Interop "utility" apps -- normally placed into `bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android` -- are *instead* placed into `bin/Debug-netcoreapp3.1` for netcoreapp3.1 builds. This ensure that things *actually build*. Locally. YMMV.
jonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
from
March 20, 2020 18:54
b39a585 to
a08e84bComparejonpryor added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Mar 21, 2020
***DO NOT MERGE*** Context: dotnet/java-interop#597 Just testing to see if dotnet/java-interop#597 works... Need to use `msbuild /restore` for all builds to allow `Java.Interop.Tools.Cecil` to build; see: dotnet#4376 (comment) Note: `$(TargetFrameworks)` throws a wrench into things. If two `$(TargetFramework)` builds share the same output directory, the `IncrementalClean` target will *remove files created by previous builds*, e.g. when e.g. `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)`. The problem here is that xamarin-android is setup so that we mirror the installation directory, with e.g. `bin/Debug` being an "installation root", and that installation root *won't* (normally?) have *both* net472 and netcoreapp3.1 outputs for the "same" project. The "solution" is to use the new `$(UtilityOutputFullPathCoreApps)` property within Java.Interop to ensure that Java.Interop "utility" apps -- normally placed into `bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android` -- are *instead* placed into `bin/Debug-netcoreapp3.1` for netcoreapp3.1 builds. This ensure that things *actually build*. Locally. YMMV.
jonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
from
March 21, 2020 03:27
a08e84b to
b5adb86Comparejonpryor added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Mar 25, 2020
***DO NOT MERGE*** Context: dotnet/java-interop#597 Just testing to see if dotnet/java-interop#597 works... Need to use `msbuild /restore` for all builds to allow `Java.Interop.Tools.Cecil` to build; see: dotnet#4376 (comment) Note: `$(TargetFrameworks)` throws a wrench into things. If two `$(TargetFramework)` builds share the same output directory, the `IncrementalClean` target will *remove files created by previous builds*, e.g. when e.g. `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)`. The problem here is that xamarin-android is setup so that we mirror the installation directory, with e.g. `bin/Debug` being an "installation root", and that installation root *won't* (normally?) have *both* net472 and netcoreapp3.1 outputs for the "same" project. The "solution" is to use the new `$(UtilityOutputFullPathCoreApps)` property within Java.Interop to ensure that Java.Interop "utility" apps -- normally placed into `bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android` -- are *instead* placed into `bin/Debug-netcoreapp3.1` for netcoreapp3.1 builds. This ensure that things *actually build*. Locally. YMMV.
jonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
from
March 25, 2020 17:52
7b08516 to
16d0019Compare***DO NOT MERGE*** Context: dotnet/java-interop#597 Just testing to see if dotnet/java-interop#597 works... Need to use `msbuild /restore` for all builds to allow `Java.Interop.Tools.Cecil` to build; see: dotnet#4376 (comment) Note: `$(TargetFrameworks)` throws a wrench into things. If two `$(TargetFramework)` builds share the same output directory, the `IncrementalClean` target will *remove files created by previous builds*, e.g. when e.g. `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)`. The problem here is that xamarin-android is setup so that we mirror the installation directory, with e.g. `bin/Debug` being an "installation root", and that installation root *won't* (normally?) have *both* net472 and netcoreapp3.1 outputs for the "same" project. The "solution" is to use the new `$(UtilityOutputFullPathCoreApps)` property within Java.Interop to ensure that Java.Interop "utility" apps -- normally placed into `bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android` -- are *instead* placed into `bin/Debug-netcoreapp3.1` for netcoreapp3.1 builds. This ensure that things *actually build*. Locally. YMMV.
jonpryorforce-pushed
the
jonp-try-ji-cecil-removal
branch
from
March 26, 2020 20:09
16d0019 to
c11909eCompareMagic Pixie Dust!
jonpryor
commented
Mar 26, 2020
ContributorAuthor
...and, related: dotnet/msbuild#3000 (comment) |
Changes: dotnet/java-interop@1a086ff...56c92c7 * dotnet/java-interop@56c92c7: [build] Remove cecil submodule (dotnet#597) * dotnet/java-interop@3091274: [build] Provide a default $(Configuration) value (dotnet#612) * dotnet/java-interop@cf3e7c2: [generator] Don't process duplicate reference assemblies (dotnet#611) * dotnet/java-interop@f5fa462: [jnienv-gen] Convert to SDK-style (dotnet#608)
jonpryor
commented
Mar 27, 2020
ContributorAuthor
Now that it builds, dotnet/java-interop#597 has been merged. Now to turn this PR into a "real" Java.Interop bump |
jonpryor
commented
Mar 27, 2020
ContributorAuthor
Squash-and-merge summary: Commit body: |
Now it's `jnienv-gen` breaking us. :-/ /Users/runner/hostedtoolcache/dotnet/sdk/3.1.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(234,5): error NETSDK1004: Assets file '/Users/runner/runners/2.165.2/work/1/s/external/Java.Interop/build-tools/jnienv-gen/obj/project.assets.json' not found. Run a NuGet package restore to generate this file. [/Users/runner/runners/2.165.2/work/1/s/external/Java.Interop/build-tools/jnienv-gen/jnienv-gen.csproj]
This file contains hidden or 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
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
DO NOT MERGE
Context: dotnet/java-interop#597
Just testing to see if dotnet/java-interop#597 works...