forked from dotnet/java-interop
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[java-interop] Migrate to C++ (dotnet#427)
Context: dotnet#354 We'd like to get `src/java-interop` buildable on Windows, ideally as a "Dynamic Link Library (DLL)" C++ project or "CMake Project". In prototyping this, a conundrum arose: the "implicitly load symbols from the 'host' executable" approach (commit 2526676) cannot work on Windows, meaning we need to use the "dylib-mono" infrastructure used in xamarin-android. The current xamarin-android dylib-mono infrastructure is all C++, which in turn means (at minimum) `java-interop-mono.c` needs to be in C++ -- if not more files -- in order to use [`dylib-mono.h`][0]. Rename `src/java-interop/*.c` to `src/java-interop/*.cc`, and port the C code to C++. Then comes the *build* conundrum: the above renaming doesn't alter `jni.c`, which will remain in C (until we want to update `build-tools/jnienv-gen`), which means we need to have a build system which supports compiling *both* C and C++ and then linking them into the shared library. There are two plausible answers here: 1. Use an actual existing build system like `cmake`. 2. Hack things until they work (5c89b90) The problem with `cmake` is that it requires an additional build-time dependency, and this repo doesn't have any provisioning infrastructure or simple way to check/assert that build-time dependencies exist; it would just error "cryptically." (It also requires that I learn CMake, which might be a good idea...) Additionally, a goal for eventual Windows support is to use a "Dynamic Link Library (DLL)" C++ project type, at least to see if it's *possible*. Start cribbing some item group names from how `.vcxproj` files work -- rename `@(Compile)` to `@(ClCompile)`, use `%(ClCompile.PreprocessorDefinitions)` to specify C++ `#define` symbols, etc. -- and rework the `BuildMac` and `BuildUnixLibraries` targets so that instead of using a single `g++` command to build source code into a shared library, use an appropriate C or C++ compiler to compile source code into object files, then use the C++ compiler to link the object files into the final shared library. This reduces patch complexity -- no introduction of CMake! -- while allowing intermixing of C and C++ code. Finally, fix a `clang` warning around the use of `DO_LOG`: java-interop-logger.cc(6,9): warning G7B4053DF: 'DO_LOG' macro redefined [-Wmacro-redefined] [/Users/jon/Dropbox/Developer/Java.Interop/src/java-interop/java-interop.csproj] Next steps: * Import & require "dylib-mono" use. "'Stand alone' mono use" should be supportable by using `NULL` for the path to load mono from, on platforms which support this. * *Actual* Windows build support. [0]: https://github.com/xamarin/xamarin-android/blob/d006fa832a8149aa9d5791bf9cc78425ca93799d/src/monodroid/jni/dylib-mono.h
- Loading branch information
Showing
8 changed files
with
127 additions
and
111 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
Oops, something went wrong.