[monodroid] Build and config jnimarshalmethod-gen.exe

[radekdoulik]

Build the tool to be used for generating the marshal methods, it will
be used when user enables it with the
AndroidGenerateJniMarshalMethods property.

Update our copy of Java.Runtime.Environment.dll.config.
Add dll maps to map libmono-android as java-interop shared library
for Java.Runtime.Environment.dll. Similar way as we do for
Java.Interop.dll in monodroid.targets

Share the dllmaps in build-tools/scripts/java-interop.dllmap

Example content of Java.Runtime.Environment.dll.config:

<configuration>
  <dllmap dll="java-interop" os="osx" target="lib/host-Darwin/libmono-android.debug.dylib" />
  <dllmap dll="java-interop" os="linux" target="lib/host-Linux/libmono-android.debug.so" />
  <dllmap dll="java-interop" os="windows" wordsize="64" target="lib/host-mxe-Win64/libmono-android.debug.dll" />
  <dllmap dll="java-interop" os="windows" wordsize="32" target="lib/host-mxe-Win32/libmono-android.debug.dll" />
  <dllmap dll="jvm.dll" os="osx" target="/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/lib/jli/libjli.dylib"/>
</configuration>

[radekdoulik]

It requires these PRs to be merged first: #1739 and dotnet/java-interop#321

[jonpryor]

Why is this needed?

Explicit <MSBuild/> invocations annoy Atsushi whenever files get out of sync. What will happen is that the .csproj isn't updated, but one of the source files for that project is updated, but the project won't necessarily be rebuilt, which later results in a "mismatch" that can only be fixed by git clean -xdf, and everyone is sad.

Additionally, I don't see why this is needed in the first place. Xamarin.Android.Tools.JniMarshalMethodGenerator.csproj is added to Xamarin.Android.sln; therefore, it should be built, eventually. The @(ProjectReference) should also ensure that the project is built.

Why is this <MSBuild/> needed at all?

[jonpryor]

Why is this needed at all?

[radekdoulik]

Probably not needed. It was there to be sure that it is available at the right time. When I removed the part that pre-generated the marshal methods in Mono.Android I didn't want to break it, so rather kept it there.

OK, I guess I will try another round.

[jonpryor]

This part seems...okay...except for two things:

1. This won't build on Windows. Can we instead use the <ReplaceFileContents/> task?
2. The output file is in $(XAInstallPrefix)xbuild\Xamarin\Android. Why is this being generated in Mono.Android.targets, which places outputs into $(XAInstallPrefix)xbuild-frameworks\...?

If this belongs anywhere, it's in src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.targets.

[radekdoulik]

I have meanwhile moved it to src/monodroid/monodroid.targets which is hopefully good place too. We handle the configs at one place and the dllmaps use the monodroid shared libraries.

I can try to use ReplaceFileContents task. Hope it could be done as an addition to speedup the merge process.

[jonpryor]

Additionally, the PR title and comment are now entirely unrelated to what the PR does.

[radekdoulik]

It is here to make sure we have $(XAInstallPrefix)xbuild\Xamarin\Android\Java.Runtime.Environment.dll.config before modifying it.

[jonpryor]

Given you have a sed -- and/or <ReplaceFileContents/> -- which can have any input path, why does $(XAInstallPrefix)xbuild\Xamarin\Android\Java.Runtime.Environment.dll.config need to exist before it's modified?

You could do, sed-wise:

sed regex... source-file > dest-file

[jonpryor]

As a non-sed-based example:

diff --git a/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.targets b/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.targets
index f60093ab..69537ee7 100644
--- a/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.targets
+++ b/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.targets
@@ -10,6 +10,7 @@
     <_GeneratedProfileClass>$(MSBuildThisFileDirectory)$(IntermediateOutputPath)Profile.g.cs</_GeneratedProfileClass>
     <BuildDependsOn>
       _GenerateXACommonProps;
+      _GenerateJavaRuntimeEnvironmentConfig;
       $(BuildDependsOn);
       _CopyExtractedMultiDexJar;
       _BuildMonoScripts;
@@ -136,6 +137,22 @@
         Replacements="@PACKAGE_VERSION@=$(ProductVersion);@PACKAGE_VERSION_BUILD@=$(XAVersionCommitCount)">
     </ReplaceFileContents>
   </Target>
+  <Target Name="_GenerateJavaRuntimeEnvironmentConfig"
+      Inputs="$(JavaInteropFullPath)\src\Java.Runtime.Environment\Java.Runtime.Environment.dll.config.in"
+      Outputs="$(OutputPath)Java.Runtime.Environment.dll.config">
+    <ReadLinesFromFile File="..\..\build-tools\scripts\java-interop.dllmap">
+      <Output TaskParameter="Lines" ItemName="_JavaInteropDllMapContent" />
+    </ReadLinesFromFile>
+    <PropertyGroup>
+      <_DllMap>@(_JavaInteropDllMapContent->'%(Identity)', '%0a')</_DllMap>
+    </PropertyGroup>
+    <Message Text="# jonp: _JavaInteropDllMapContent=```$(_DllMap)```" />
+    <ReplaceFileContents
+        SourceFile="$(JavaInteropFullPath)\src\Java.Runtime.Environment\Java.Runtime.Environment.dll.config.in"
+        DestinationFile="$(OutputPath)Java.Runtime.Environment.dll.config"
+        Replacements="@JAVA_RUNTIME_ENVIRONMENT_DLLMAP@=$(_DllMap)"
+    />
+  </Target>
   <Target Name="_GenerateProfileClass"
       BeforeTargets="CoreCompile"
       Inputs="@(_SharedRuntimeAssemblies)"

The above generates bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/Java.Runtime.Environment.dll.config with contents:

<configuration>
  <dllmap dll="jvm.dll" os="@OS_NAME@" target="@JI_JVM_PATH@"/>
<dllmap dll="java-interop" os="osx" target="lib/host-Darwin/libmono-android.debug.dylib" />
<dllmap dll="java-interop" os="linux" target="lib/host-Linux/libmono-android.debug.so" />
<dllmap dll="java-interop" os="windows" wordsize="64" target="lib/host-mxe-Win64/libmono-android.debug.dll" />
<dllmap dll="java-interop" os="windows" wordsize="32" target="lib/host-mxe-Win32/libmono-android.debug.dll" />
</configuration>

Which admittedly is a tad weird, as we have that jvm.dll entry, but that's plausibly fixed .

[radekdoulik]

Updated to use ReplaceFileContents. Had to fiddle with the text a bit to avoid the task to parse the replacement text as it contains = chars.

[radekdoulik]

Lets handle the jvm path in next PR(s).