aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/windows/WindowsJniLoader.java
Commit message (Collapse)AuthorAge
* Windows: remove test-specific JNI loaderGravatar Laszlo Csomor2017-01-12
| | | | | | | | | | WindowsJniLoader.loadJniForTesting is just a special case of what WindowsJniLoader.loadJni already does, so we can just use the latter. -- PiperOrigin-RevId: 144224388 MOS_MIGRATED_REVID=144224388
* Load JNI library on Windows from the runfiles tree as a fallbackGravatar Damien Martin-Guillerez2016-12-28
| | | | | | | | | | | | | | | | | This is the behavior of the UnixJniLoader. In order to do that, this change also moved the runfiles support on Windows in its own library that the WindowsJniLoader can use to load the JNI library from tests. Also add the JNI library on Windows to all test that use the JNI library on Unix. Fixes #2300. -- Change-Id: I2eb9207c3aa310d95912a48f64f676957c47cd34 Reviewed-on: https://cr.bazel.build/8045 PiperOrigin-RevId: 143114397 MOS_MIGRATED_REVID=143114397
* Use the subprocess factory that uses the Win32 API on Windows.Gravatar Lukacs Berki2016-07-04
| | | | | | | We should really do something about the mess that is loading our JNI libraries -- io.bazel.EnableJNI is mentioned eight times in the code in various diverse contexts. This change is not the right place to do it, though. -- MOS_MIGRATED_REVID=126570481
* Add native process management for Windows and its Java bindings (without a ↵Gravatar Lukacs Berki2016-07-01
| | | | | | | sane Java API for now) -- MOS_MIGRATED_REVID=126306559
* Add skeleton code for a JNI .DLL on Windows.Gravatar Lukacs T. Berki2016-06-27
Tested by hacking in a call to a JNI method into BatchMain.java . -- Change-Id: I77b0731fa6b81f8cbc80cf2a31d427764fad6ad1 Reviewed-on: https://bazel-review.googlesource.com/#/c/3908/ MOS_MIGRATED_REVID=125955521
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 21:15:06 +0000