aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/windows
Commit message (Collapse)AuthorAge
* Windows, JNI: arg for argv0 in nativeCreateProcessGravatar Laszlo Csomor2017-01-12
| | | | | | | | | | | | | | | | | | | Add a separate argument to nativeCreateProcess for argv[0] specifically, and another for the rest of the args. In a subsequent change I'll add code to compute the 8dot3 style short name of the argv[0] so we can use longer paths for executables in CreateProcessA than we normally could. This is the same approach as used in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144311562 MOS_MIGRATED_REVID=144311562
* 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
* Windows: resolve shortened pathsGravatar Laszlo Csomor2017-01-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: resolve "C:/progra~1" style paths, don't cache failed resolutions in the parent's Path.children When creating WindowsPath objects, resolve the "C:/progra~1" style paths to "C:/program files". This enables us to correctly compare paths on Windows. Without this canonicalization we incorrectly determine "C:/progra~1" and "C:/program files" to be different when they are actually the same. We only attempt to resolve such paths if the name looks like it's an abbreviated path. If resolution fails, probably due to the path not existing, then we don't cache this Path object in the parent's `children` list. This avoids stale cache entries in case the path springs into existence later in the server's lifetime. Fixes https://github.com/bazelbuild/bazel/issues/2145 We also need to rectify https://github.com/bazelbuild/bazel/issues/2173 -- PiperOrigin-RevId: 143442134 MOS_MIGRATED_REVID=143442134
* 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
* Windows JNI: ensure JNI is loaded for getLongPathGravatar Laszlo Csomor2016-12-21
| | | | | | -- PiperOrigin-RevId: 142670226 MOS_MIGRATED_REVID=142670226
* Windows, JNI: implement nativeGetLongPathGravatar Laszlo Csomor2016-12-15
| | | | | | | | | | | | | | | | | | | | Implement a JNI method that can resolve 8dot3 style paths. This is necessary because we need to be able to compare 8dot3 style paths and long paths [1], and because implementing this correctly in Java seems to be impossible [2]. This change also adds tests for the JNI isJunction implementation. See https://github.com/bazelbuild/bazel/issues/2101 [1] https://github.com/bazelbuild/bazel/issues/2145 [2] https://github.com/bazelbuild/bazel/issues/2145#issuecomment-266766716 -- PiperOrigin-RevId: 142123750 MOS_MIGRATED_REVID=142123750
* Windows JNI library: prepare for widechar WinAPIGravatar Laszlo Csomor2016-12-06
| | | | | | | | | | | | | | | | | | This change: - renames windows_error_handling.* to windows_util.* - moves most stuff except for the JNI method implementations into the new windows_util namespace - implements a jstring to wchar string converter - uses GetFileAttributesW in windows_file_operations.cc See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 141187291 MOS_MIGRATED_REVID=141187291
* Fixed a bug during bootstrapGravatar Yun Peng2016-09-08
| | | | | | | | | Fixed #1732 RELNOTES: -- MOS_MIGRATED_REVID=132436686
* Windows, JNI: implement native isJunction method.Gravatar Laszlo Csomor2016-09-06
| | | | | | | WindowsFileSystem.java does not yet use it. -- MOS_MIGRATED_REVID=132043739
* Windows, JNI: do not load windows_jni.dll twice.Gravatar Laszlo Csomor2016-08-31
| | | | | | | | | WindowsProcesses.ensureJni() was duplicating the work of WindowsJniLoader.loadJni(); this change removes the former and replaces the only call site with the latter. -- MOS_MIGRATED_REVID=131806917
* Implement timeouts on Windows.Gravatar Lukacs Berki2016-08-22
| | | | | | | Makes #1664 much less acute. -- MOS_MIGRATED_REVID=130750731
* Fix capturing stdin/stdout on Windows.Gravatar Dmitry Lomov2016-07-11
| | | | | | | | | | | 1. Return EOF for streams representing Windows process pipes. 2. Fix the timing of process.close() 3. Un-synchronized reading of stderr and stdout. -- Change-Id: Iec98f45db9984be2c2b066962801cbd3ca60da3f Reviewed-on: https://bazel-review.googlesource.com/#/c/4000/ MOS_MIGRATED_REVID=126910063
* Propagate the system root to every process created in WindowsSubprocessFactory.Gravatar Lukacs Berki2016-07-07
| | | | | | | | | | | This is apparently required by some versions MSVCRT.DLL including the one used in the CL.EXE we happen to be using for testing. This was learned by reading the source code of OpenJDK. Fixes #1480. -- MOS_MIGRATED_REVID=126786461
* Make Windows process management nicer.Gravatar Lukacs Berki2016-07-06
| | | | | | | | | Subprocesses now get killed if the Bazel server itself is killed and so do their subprocesses. Also implemented Subprocess#close() so that we get a little more control over when the native structures are cleaned up. -- MOS_MIGRATED_REVID=126628000
* 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 an implementation for SubprocessFactory based on the new JNI interface ↵Gravatar Lukacs Berki2016-07-04
| | | | | | | | | | | to Windows process management. With this change, Bazel can build itself using native Windows process management and Ctrl-C works in server mode as expected. Yay! Flipping the flag will come in a separate change that's easy to roll back if need be. -- MOS_MIGRATED_REVID=126408264
* 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
* Make "bazel info server_pid" work on Windows.Gravatar Lukacs Berki2016-06-29
| | | | | | | | | This is the first actual use of Windows JNI! Also a cleanup of ProcessUtils. Injecting a mock implementation was never used. -- MOS_MIGRATED_REVID=126068832
* 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-03 06:37:52 +0000