[Java.Interop-PerformanceTests] Support .NET Core 3.1

[jonpryor]

Build Java.Interop-PerformanceTests.csproj for netcoreapp3.1, and
run it using dotnet test.

This in turn requires building the tests/NativeTiming native library
for .NET Core.

Add a cmake-based build system for tests/NativeTiming.

Update core-tests.yaml so that dotnet test is used to run both
the net472 and netcoreapp3.1 versions of
Java.Interop-PerformanceTests.dll.

[jonpryor]

After lots of hair pulling, the repro for the Mac - .NET Core failure requires two steps;

1. Use the "dotnet" build scenario.
2. Use the Release configuration

% make prepare-core CONFIGURATION=Release
% dotnet build Java.Interop.sln -c Release -t:Prepare
% dotnet build Java.Interop.sln -c Release -m:1 /v:diag > b.txt

Also note that -m:1 is required, otherwise you'll get different build failures.

What appears to be happening is that tests/NativeTiming/NativeTiming.csproj is trying to load bin/BuildDebug/JdkInfo.props -- the Debug configuration! -- which doesn't exist. Because it doesn't exist, @(JdkIncludePath) isn't set, and thus <jni.h> can't be found.

A previous version used <Project Sdk="Project Sdk="Microsoft.Build.NoTargets">, which emits a warning:

tests/NativeTiming/Directory.Build.targets : 
warning MSB4011: "…/Java.Interop/packages/microsoft.build.notargets/2.0.1/Sdk/Sdk.props"
cannot be imported again. It was already imported at
"…/Java.Interop/tests/NativeTiming/NativeTiming.csproj"

Fixing this warning doesn't fix the build failure.

[jonpryor]

The problem is the .sln! If a .csproj isn't in the .sln, then it "ignores" dotnet build -c, apparently. :-/

[jonpryor]

While using ninja was suggested (via cmake -G Ninja), I stayed with Makefiles because they actually worked on CI without additional provisioning; ninja isn't pre-installed.

Additionally, the Windows cmake default of cmake -G "Visual Studio 16 2019" doesn't work (I didn't investigate why). Using cmake -G "NMake Makefiles" does work, and is preinstalled, so I went with that.

[jonpryor]

…or all native compilation on Windows is possibly "out", as cl isn't in %PATH% either! https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4504944&view=logs&j=f31c9f97-4411-58e7-49ac-fc73f645e6b6&t=cbeb8522-7b64-5cc0-7bee-eff0e164a409

  cmake -G "NMake Makefiles" -S . -B obj\\Release\ "-DJDK_INCLUDE_LIST=C:\Program Files\Java\jdk8u282-b08\include;C:\Program Files\Java\jdk8u282-b08\include\win32"
  -- The C compiler identification is unknown
  CMake Error at CMakeLists.txt:3 (project):
    The CMAKE_C_COMPILER:
  
      cl
  
    is not a full path and was not found in the PATH.
  
    To use the NMake generator with Visual C++, cmake must be run from a shell
    that can use the compiler cl from the command line.  This environment is
    unable to invoke the cl compiler.  To fix this problem, run cmake from the
    Visual Studio Command Prompt (vcvarsall.bat).
  
    Tell CMake where to find the compiler by setting either the environment
    variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
    the compiler, or to the compiler

[jonpryor]

getting cl.exe into %PATH% is "interesting"; executing vcvars64.bat (or any other vcvars*.bat script) fails: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4505234&view=logs&j=f31c9f97-4411-58e7-49ac-fc73f645e6b6&t=2bcaa12b-2f4b-5b1f-c519-10308f653190

**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.8.5
** Copyright (c) 2020 Microsoft Corporation
**********************************************************************
[ERROR:team_explorer.bat] Directory not found : "CommonExtensions\Microsoft\TeamFoundation\Team Explorer"
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1

Which is…something.

Trying a Horrible Hack in which I explicitly set %PATH% to include a directory that may (?) contain cl.exe:

variables:
  VSInstallDir: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise
  Cl64Path: $(VSInstallDir)\VC\Tools\MSVC\14.28.29334\bin\Hostx64\x64

jobs:
- job: windows_build
  …
  steps:
  - script: >
      echo "##vso[task.setvariable variable=PATH]%PATH%;$(Cl64Path)"
    displayName: 'Add cl to PATH'

which is guaranteed to break every time the VM is changed…

[jonpryor]

Perhaps unsurprisingly, setting %PATH% also failed: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4505376&view=logs&j=10b5dba2-0c78-5c70-4079-bab96311b95e&t=3838b6a3-21fa-59b7-5217-f31a6517c4b7

Surprisingly (to me), the build logs don't print out what %PATH% is, so I can't tell if it's correct either.

[jonpryor]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jonpryor]

…and now we hit: https://stackoverflow.com/questions/9356135/link-fatal-error-lnk-1104-cannot-open-file-libcmt-lib

  LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'

Looks like I need to run vcvars32.bat, but my previous attempt to do so had failed. :-/

Maybe if I try the "item group search" idea and run it inside the <Exec/>?

[jonpryor]

Current iteration has everything building except Windows + .NET Core.

[jonpryor]

My guess is that on Windows - .NET Framework, msbuild defines the VSINSTALLROOT environment variable -- which allows vcvarsall.bat to be found -- while Windows - .NET Core does not define VSINSTALLROOT.

What's funny is that the Windows .NET Core build does have some environment variables with Visual Studio in the value -- for VS 14:

VS140COMNTOOLS = C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\

[jonpryor]

Squash-and-merge commit message body:

Context: https://github.com/xamarin/java.interop/pull/808#issuecomment-786370513
Context: https://github.com/dotnet/runtime/blob/e1e46a8d2ca9c2c932c8ceb61f884c7c82351442/eng/native/init-compiler-and-cmake.cmd
Context: https://github.com/dotnet/runtime/blob/e1e46a8d2ca9c2c932c8ceb61f884c7c82351442/src/mono/mono.proj#L362

Build `Java.Interop-PerformanceTests.csproj` for `netstandard2.0`, and
run it using `dotnet test`.

This in turn requires building the `tests/NativeTiming` native library
for .NET Core, which in turn requires moving away from the
Visual Studio for Mac (née Xamarin Studio) -based `.cproj` file.
Replace `NativeTiming.cproj` with a `Microsoft.Build.NoTargets`-
based `NativeTiming.csproj` file, so that it can be referenced and
built by `msbuild` and `dotnet build`.

Update `core-tests.yaml` so that `dotnet test` is used to run both
the net472 and netcoreapp3.1 versions of
`Java.Interop-PerformanceTests.dll.`

Note (for posterity): if a `.*proj` file depends upon
`$(Configuration)`, it *must also* be added to `Java.Interop.sln`.
Failure to do so will mean that when building the project in
*Release* configuration, the *new* project will instead be built in
*Debug* configuration, resulting in all manner of head-scratching.

~~ cmake & Windows & C, Oh My! ~~

Add a `cmake`+"Makefile"-based build system for `tests/NativeTiming`.
Note that in order to build on Windows, `vcvarsall.bat` *must* be
executed *before* using any "native Visual Studio toolchain" commands
such as `cl.exe`.  Additionally, for reasons not currently understood,
running `vcvarsall.bat` *from YAML* -- on the hope/assumption that
this would add`cl.exe`/etc. to `%PATH%` and usable everywhere --
*did not work*.  (Note that `vcvarsall.bat` requires that you specify
which CPU architecture to support; we currently use `x86_amd64`.)

In order for the .NET Core-based build to *find* `vcvarsall.bat`, add
a new `VSInstallRoot` YAML variable.  The .NET Framework-based builds
already have a `%VSINSTALLROOT%` environmemnt variable, as do the
**Developer Command Prompt for VS\*** commands.

Thus, on Windows, we do:

	call "%VSINSTALLROOT%\VC\Auxiliary\Build\vcvarsall.bat x86_amd64 && ^
	  cmake -G "NMake Makefiles" -S . -B obj\Debug -DJDK_INCLUDE_LIST=…"
	…
	call "%VSINSTALLROOT%\VC\Auxiliary\Build\vcvarsall.bat x86_amd64 && ^
	  cd obj\Debug && ^
	  nmake VERSION=1

[jpobst]

I would prefer not to add diag, as 99% of the time it just makes the logs harder to read. We can look at recording a binlog and saving it as an artifact.