aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/windows
Commit message (Collapse)AuthorAge
* Windows: Android BusyBox can access the JNI libGravatar Laszlo Csomor2017-07-31
| | | | | | | | | | | | | | | Add a data-dependency on the windows_jni.dll from the BusyBox in BUILD.tools, so the BusyBox in @build_tools// can actually find it at runtime. Also update the script that builds the .dll so that it works if the source files have an "external/bazel_tools/" prefix. Related to https://github.com/bazelbuild/bazel/issues/3264 Change-Id: I005e9d2c00253a59d2cd5cc9f3a93528dc4d2e9e PiperOrigin-RevId: 163691320
* Windows, Android BusyBox: create JunctionCreatorGravatar Laszlo Csomor2017-07-10
| | | | | | | | | | | Introduce the JunctionCreator classes that the Android BusyBox can use to work around path length limitations on Windows. See https://github.com/bazelbuild/bazel/issues/3264 Change-Id: Ia5ee39f0635dcc2690ffb1755dc56d21e7bc7536 PiperOrigin-RevId: 161378422
* build_windows_jni.sh: move file to subdirectoryGravatar Laszlo Csomor2017-07-05
| | | | | | | | | | | | | The script more logically belongs in src/main/native/windows than in src/main/native. Also move the //src/main/native:windows_jni rule into //src/main/native/windows:windows_jni, so the logic of building the JNI library is fully contained in that package. Change-Id: I96e19003932cc0ddc5af3471b0b31a1aec09b8fa PiperOrigin-RevId: 160876594
* Windows, JNI: move around sourcesGravatar Laszlo Csomor2017-07-03
| | | | | | | | | | | | | | | | | | | | | | | | Move the Java JNI sources to a separate package: c.g.devtools.build.lib.windows.jni and c.g.devtools.build.lib.windows.runfiles. Make the native method declarations private, create public wrapper methods for them that ensure that the JNI library is loaded. Split the C++ JNI source processes.cc into two parts (processes-jni.cc and file-jni.cc), extract common functionality to jni-util.{h,cc}. This change preparse the code for Android rule support on Windows, specifically it lets the Android BusyBox use the file JNI library so it can create junctions on Windows to work around long path issues when calling external tools. See https://github.com/bazelbuild/bazel/issues/3264 Change-Id: I7f1a746d73f822ae419d11b893a91f4eb45d64da PiperOrigin-RevId: 160643355
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* Windows, Bazel client: pass Unix root as JVM flagGravatar Laszlo Csomor2017-06-13
| | | | | | | | | | | | | The Bazel client will pass the --host_jvm_args=-Dbazel.windows_unix_root=<path> flag to the server (computed from $BAZEL_SH), and the server will no longer shell out to cygpath to compute this value. Fixes https://github.com/bazelbuild/bazel/issues/2983 Change-Id: Iacc2e2eb70eacafdf7bbcad68d375ba9eadc6ee1 PiperOrigin-RevId: 158830675
* Windows: Create a dangling junction when symlink target doesn't existGravatar Yun Peng2017-06-01
| | | | | | | | | | | | | | On Unix system, `ln -s foo bar` will create an dangling symlink bar -> foo even foo doesn't exist. The current implementation of createSymbolicLink for Windows fails in this situtation. And this lead to #2474. In this change, we create a dangling junction when the target doesn't exist which mimics the behavior on Unix. Fixed https://github.com/bazelbuild/bazel/issues/2474 Change-Id: I442ca3e2fb20b76c9b5bbfee903299fe51481f43 PiperOrigin-RevId: 157694631
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | 'create' method. This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment). This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations. RELNOTES: None PiperOrigin-RevId: 152145768
* Restructure Path#getCachedChildPath to make direct method calls without ↵Gravatar nharmata2017-04-04
| | | | | | | | allocating a garbage TranslatedPath object. RELNOTES: None PiperOrigin-RevId: 152130170
* Move UnixFileSystem to lib.unix, WindowsFileSystem to lib.windowsGravatar Ulf Adams2017-02-28
| | | | | | -- PiperOrigin-RevId: 148749485 MOS_MIGRATED_REVID=148749485
* Windows: use JNI CreateJunction in Java code Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | | | | Use the new CreateJunction in the Windows JNI code every time we need to create junctions. This means updating WindowsFileOperations and related tests. Add test for WindowsFileSystem.createSymbolicLink. See https://github.com/bazelbuild/bazel/issues/2238 -- Change-Id: I5827e2e70e8e147f5f102fabf95fa9a148b3bcdc Reviewed-on: https://cr.bazel.build/8896 PiperOrigin-RevId: 147598107 MOS_MIGRATED_REVID=147598107
* Windows: fix off-by-one errors with MAX_PATHGravatar Laszlo Csomor2017-02-07
| | | | | | | | | | | | | | | | | | In almost every place we compared paths against MAX_PATH, we had it wrong. MAX_PATH is the null-terminated maximum length, so paths exactly MAX_PATH long (not counting the null-terminator) were incorrectly considered short. Also fix the error message in the MSVC python wrapper, because it reported an incorrect path length limit in the warning message. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 146762382 MOS_MIGRATED_REVID=146762382
* Global cleanup change.Gravatar Googler2017-01-25
| | | | | | -- PiperOrigin-RevId: 145473478 MOS_MIGRATED_REVID=145473478
* Windows, JNI: make it work with long pathsGravatar Laszlo Csomor2017-01-16
| | | | | | | | | | | | | | When spawning a new process with CreateProcessA, convert argv0 to a 8dot3 style short path so we can support longer paths than MAX_PATH. This is the same approach we did in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144613589 MOS_MIGRATED_REVID=144613589
* 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-04 09:19:50 +0000