-
Notifications
You must be signed in to change notification settings - Fork 58
[jcw-gen] Build jcw-gen.exe
into $(UtilityOutputFullPath)
#145
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
Merged
Conversation
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
Context: https://github.com/mono/Embeddinator-4000 Context: dotnet@b6431ac Embeddinator-4000 is an in-progress utility to easily allow Java/C/Objective-C/etc. to consume .NET CIL. For example, it would be desirable to be able to "export" a `.dll` into an Android `.aar` file, so that Java developers using Android Studio can consume and use managed assemblies in a straightforward manner. Part of making this work will be to generate Java "bindings" of an assembly. "Funny" thing: we already partially have that: `jcw-gen.exe` will take an assembly and generate Java Callable Wrappers for `Java.Lang.Object` subclasses from that assembly. Aside from the base class requirement, this is (more or less) what Embeddinator-4000 requires...except that Embeddinator-4000 wants to handle *all* managed types, not just `Java.Lang.Object` subclasses. That said, at some point it will be desirable for "transparent" use of `Java.Lang.Object` subclasses; Embeddinator-4000 can't (reasonably or sanely) use it's "normal" non-`Java.Lang.Object`-aware generator to bind `Java.Lang.Object` subclasses; for starters, the base class will be completely wrong (`Java.Lang.Object` instead of `java.lang.Object`!). Embeddinator-4000 *could* use the `Java.Interop.Tools.JavaCallableWrappers` assembly in order to perform this work, but that would require that Embeddinator-4000 reference Java.Interop or otherwise "obtain" an assembly to build against, complicating bootstrapping and ongoing maintenance. Instead, Embeddinator-4000 can use our existing command-line code generation interface, `jcw-gen.exe`. This simplifies the build -- at the expense of runtime, as now you need to specify where `jcw-gen.exe` is -- and provides a "break" between repositories. Update `jcw-gen.csproj` so that it's `$(OutputPath)` is `$(UtilityOutputFullPath)`, as is the case for `class-parse`, `generator`, and `logcat-parse`, so that `jcw-gen.exe` can be distributed as part of Xamarin.Android.
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this pull request
Dec 16, 2021
Changes: dotnet/android-tools@34e98e2...db125a7 * dotnet/android-tools@db125a7: [build] Add d17-* as a branch trigger * dotnet/android-tools@f2cbc6a: Add resource dlls to MicroBuild signing. (dotnet#145) * dotnet/android-tools@35c89dd: Update MaximumCompatibleNDKMajorVersion to be 23 (dotnet#144) * dotnet/android-tools@0a22957: [Xamarin.Android.Tools.AndroidSdk] Parse Properties after header (dotnet#143) * dotnet/android-tools@dac3a47: [Xamarin.Android.Tools.AndroidSdk] Add API-31 to KnownVersions (dotnet#141) * dotnet/android-tools@fc976d8: [Xamarin.Android.Tools.AndroidSdk] Add JdkInfo.GetSupportedJdkInfos() (dotnet#142)
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this pull request
Mar 14, 2022
Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1397171 Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1433453 Changes: http://github.com/xamarin/xamarin-android-tools/compare/34e98e2b65917d105169f868b5648f67e68b6784...f4c44e2ac2d91396226f31e8c200464ecc65f648 * dotnet/android-tools@f4c44e2: [Xamarin.Android.Tools.AndroidSdk] Attributes can be null! (dotnet#158) * dotnet/android-tools@f0b3abd: Revert "[Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-32 (dotnet#156)" * dotnet/android-tools@bbe85df: [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-32 (dotnet#156) * dotnet/android-tools@a7f4d30: [ci] Mention new NuGet feed and release (dotnet#153) * dotnet/android-tools@85ae77f: Merge pull request dotnet#152 from xamarin/dev/mattnorflus/SigningMigration * dotnet/android-tools@dd34e54: Adding condition to GetFilesToSign to only include files if build configuration is Release * dotnet/android-tools@0e80ea1: Bump LibZipSharp to 2.0.3 (dotnet#151) * dotnet/android-tools@d0ab6ac: Fix Typo in commit 0dcf7172 (dotnet#150) * dotnet/android-tools@0dcf717: Bump LibZipSharp to 2.0.2 (dotnet#149) * dotnet/android-tools@db125a7: [build] Add d17-* as a branch trigger * dotnet/android-tools@f2cbc6a: Add resource dlls to MicroBuild signing. (dotnet#145) * dotnet/android-tools@35c89dd: Update MaximumCompatibleNDKMajorVersion to be 23 (dotnet#144) * dotnet/android-tools@0a22957: [Xamarin.Android.Tools.AndroidSdk] Parse Properties after header (dotnet#143) * dotnet/android-tools@dac3a47: [Xamarin.Android.Tools.AndroidSdk] Add API-31 to KnownVersions (dotnet#141) * dotnet/android-tools@fc976d8: [Xamarin.Android.Tools.AndroidSdk] Add JdkInfo.GetSupportedJdkInfos() (dotnet#142)
jonpryor
added a commit
that referenced
this pull request
Mar 14, 2022
Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1397171 Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1433453 Changes: http://github.com/xamarin/xamarin-android-tools/compare/34e98e2b65917d105169f868b5648f67e68b6784...f4c44e2ac2d91396226f31e8c200464ecc65f648 * dotnet/android-tools@f4c44e2: [Xamarin.Android.Tools.AndroidSdk] Attributes can be null! (#158) * dotnet/android-tools@f0b3abd: Revert "[Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-32 (#156)" * dotnet/android-tools@bbe85df: [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-32 (#156) * dotnet/android-tools@a7f4d30: [ci] Mention new NuGet feed and release (#153) * dotnet/android-tools@85ae77f: Merge pull request #152 from xamarin/dev/mattnorflus/SigningMigration * dotnet/android-tools@dd34e54: Adding condition to GetFilesToSign to only include files if build configuration is Release * dotnet/android-tools@0e80ea1: Bump LibZipSharp to 2.0.3 (#151) * dotnet/android-tools@d0ab6ac: Fix Typo in commit 0dcf7172 (#150) * dotnet/android-tools@0dcf717: Bump LibZipSharp to 2.0.2 (#149) * dotnet/android-tools@db125a7: [build] Add d17-* as a branch trigger * dotnet/android-tools@f2cbc6a: Add resource dlls to MicroBuild signing. (#145) * dotnet/android-tools@35c89dd: Update MaximumCompatibleNDKMajorVersion to be 23 (#144) * dotnet/android-tools@0a22957: [Xamarin.Android.Tools.AndroidSdk] Parse Properties after header (#143) * dotnet/android-tools@dac3a47: [Xamarin.Android.Tools.AndroidSdk] Add API-31 to KnownVersions (#141) * dotnet/android-tools@fc976d8: [Xamarin.Android.Tools.AndroidSdk] Add JdkInfo.GetSupportedJdkInfos() (#142)
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.
Context: https://github.com/mono/Embeddinator-4000
Context: b6431ac
Embeddinator-4000 is an in-progress utility to easily allow
Java/C/Objective-C/etc. to consume .NET CIL. For example, it would be
desirable to be able to "export" a
.dll
into an Android.aar
file,so that Java developers using Android Studio can consume and use
managed assemblies in a straightforward manner.
Part of making this work will be to generate Java "bindings" of an
assembly.
"Funny" thing: we already partially have that:
jcw-gen.exe
will takean assembly and generate Java Callable Wrappers for
Java.Lang.Object
subclasses from that assembly. Aside from the base class requirement,
this is (more or less) what Embeddinator-4000 requires...except that
Embeddinator-4000 wants to handle all managed types, not just
Java.Lang.Object
subclasses.That said, at some point it will be desirable for "transparent" use of
Java.Lang.Object
subclasses; Embeddinator-4000 can't (reasonably orsanely) use it's "normal" non-
Java.Lang.Object
-aware generator tobind
Java.Lang.Object
subclasses; for starters, the base class willbe completely wrong (
Java.Lang.Object
instead ofjava.lang.Object
!).Embeddinator-4000 could use the
Java.Interop.Tools.JavaCallableWrappers
assembly in order to performthis work, but that would require that Embeddinator-4000 reference
Java.Interop or otherwise "obtain" an assembly to build against,
complicating bootstrapping and ongoing maintenance.
Instead, Embeddinator-4000 can use our existing command-line code
generation interface,
jcw-gen.exe
. This simplifies the build --at the expense of runtime, as now you need to specify where
jcw-gen.exe
is -- and provides a "break" between repositories.Update
jcw-gen.csproj
so that it's$(OutputPath)
is$(UtilityOutputFullPath)
, as is the case forclass-parse
,generator
, andlogcat-parse
, so thatjcw-gen.exe
can bedistributed as part of Xamarin.Android.