We do not need the python module's find_installation() for this, as this
does various things to set up building and installing python modules
(pure python and C-API). This functionality is already tested in the
python tests.
Elsewhere, when we just need an interpreter capable of running python
scripts in order to guarantee a useful scripting language for custom
commands, it suffices to use find_program(), which does not run an
introspection script or do module imports, and is thus faster and
a bit cleaner.
Either way, both methods are guaranteed to find the python3 interpreter,
deferring to mesonlib.python_command for that guarantee.
test "71 summary" can sometimes return the python command with the
".exe" part all uppercased for mysterious Windows reasons. Smooth this
over with ExternalProgram.
Darwin-based systems, at least macOS, provide various JDK executable
stubs in
/System/Library/Frameworks/JavaVM.framework/Versions/*/Commands.
These stubs are placed in such a way that they break the heuristics of
the JNI system dependency. If a javac being analyzed to find a Java home
is a stub, use /usr/libexec/java_home.
See https://stackoverflow.com/a/15133344/7572728 for more details.
Closes#11173
JNI is a more apt name because it currently only supports the JNI. I
also believe that CMake uses the terminology JNI here as well.
JNI is currently the only way to interact with the JVM through native
code, but there is a project called "Project Panama" which aims to be
another way for native code to interact with the JVM.
After implementing a much more extensive Java native module than what
currently exists in the tests, I found shortcomings.
1. You need to be able to pass multiple Java files.
2. Meson needs more information to better track the generated native
headers.
3. Meson wasn't tracking the header files generated from inner classes.
This new function should fix all the issues the old function had with
room to grow should more functionality need to be added. What I
implemented here in this new function is essentially what I have done in
the Heterogeneous-Memory Storage Engine's Java bindings.
Because we are racing here. In reality *all* of the java in that target
may rely on the generated file, so we need to block all of them, like we
would for headers in C/C++.
To allow the javac -implicit:class behaviour to know where to find
generated .java files then the build directory for the target is also
added to the -sourcefile path.
Although only one file is passed to javac at a time, if your code has
any inter-file dependencies javac still needs to know how to find other
source files for its -implicit:class feature to work whereby it will
automatically also compile files that the given file depends on.
-implicit:class is the default, practical, behaviour of javac since
otherwise it would be necessary to declare the class dependencies
for parallel java builds to be feasible.
Passing "include_directory: include_directory('.')" to jar() causes
-souredir <path/to/top/of/java/src> to be passed to javac which then
enables your source code to have inter-file class dependencies -
assuming none of your source code is generated.
This ensures that '.' is included by default.
The -sourcepath option can't be passed multiple times to javac, since it
simply overrides prior arguments. Instead -sourcepath takes a colon (or
semi-colon on windows) separated list of paths.
Eli Schwartz