Closed jpobst closed 9 months ago
We should probably instead add tests/invocation-overhead/jni-api.h
and tests/invocation-overhead/jni.c
, and update tests/invocation-overhead/jni.cs
, as these are useful ways to see what build-tools/jnienv-gen
output is, without needing to build the repo itself and look at e.g. src/Java.Interop/obj/Debug/net7.0/JniEnvironment.g.cs
or src/java-interop/obj/Debug-net7.0/jni.c
.
For example, consider 0f1efebd68c4f234eab1e812a0985517f12e66a2, which updated jnienv-gen
, and also included updates to tests/invocation-overhead/jni.cs
. This made code review easier -- at least I'd like to think so -- because the changes introduced to jnienv-gen
were visible in the same PR as changes to jni.cs
.
Sounds good to me. This solution also fulfills my desire of appeasing git
. 😁
I'll update this PR to do this instead.
Superseded by https://github.com/xamarin/java.interop/pull/1175.
Building the
Java.Interop.sln
solution always produces some generated files thatgit
wants to try to commit:Ignore these files with
.gitignore
.Note that the first time we generate
jni.cs
we need to manually add it to@(Compile)
because the wildcard expansion has already executed at that point. Additional times the file gets regenerated we useKeepDuplicates='false'
to prevent a duplicate@(Compile)
file warning.