| Age | Commit message (Collapse) | Author |
|---|
|
This allows someone to link against libjvm.so and libjawt.so.
|
|
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.
|
|
java.generate_native_headers()
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.
|
|
The Java module will serve as a source for easing Java development
within Meson. Currently it only supports generating native header files.
|
|
and clean up all outstanding issues
Skip 'test cases/common/141 special characters/meson.build' since it
intentionally uses trailing newlines.
|
|
The JDK system dependency is important for detecting JDK include paths
that may be useful when developing a JNI interface.
|
|
|
|
We really should be documenting these in an easy to find and reference
place.
|
|
|
|
|
|
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++.
|
|
Otherwise, passing result of custom_target() to jar() target is ignored
and won't be compiled resulting in build fail.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
