aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/native/windows
Commit message (Collapse)AuthorAge
* isable_presubmitGravatar Googler2018-01-10
| | | | PiperOrigin-RevId: 181491528
* Shell code cleanupGravatar Androbin2017-12-14
| | | | | | | | | | | | - Argument mixes string and array. Use * or separate argument. - Quote the grep pattern so the shell won't interpret it. - Use "${var:?}" to ensure this never expands to /* . - > is for string comparisons. Use -gt instead. - Quote the parameter to -name so the shell won't interpret it. Closes #4163. PiperOrigin-RevId: 179042046
* Add BAZEL_VC and JAVA_HOME to build_windows_jni.shGravatar Loo Rong Jie2017-12-04
| | | | | | | | | | User might have Visual C++ Build Tools and JDK installed at non-default location, but they are still usable for bootstrapping. PS: I used Visual C++ 2017 15.3 for bootstrapping, there is a nice 1.5MB size reduction in final `bazel.exe` compared with `bazel-0.7.0-without-jdk-windows-x86_64.exe`. Closes #3943. PiperOrigin-RevId: 177815687
* Windows: Don't leak any handles from Bazel client to Bazel serverGravatar Yun Peng2017-12-01
| | | | | | | | | | | Explicitly specify which handles to inherit Fixes https://github.com/bazelbuild/bazel/issues/4193 Fixes https://github.com/bazelbuild/bazel/issues/2182 Fixes https://github.com/bazelbuild/bazel/issues/2248 Change-Id: Ifa0201a6764c633016784c245d480542966efc6d PiperOrigin-RevId: 177564007
* Windows,JNI: check cmd length for CreateProcessGravatar Laszlo Csomor2017-11-16
| | | | | | | | | | | | | | | | | Error out if the command we try to pass to CreateProcess is longer than the limit. Doing so results in a nicer error message than "The parameter is incorrect" which is confusing. In this commit I also improve the error reporting of CreateProcessWithExplicitHandles. See https://github.com/bazelbuild/bazel/issues/4083 See https://github.com/bazelbuild/bazel/issues/4096 Change-Id: I00ec52238706fd8140483eddb488c3069eaa7814 PiperOrigin-RevId: 175969789
* Only copy necessary sources for //src/main/native:embedded_tools.Gravatar Xin Gao2017-11-09
| | | | | Change-Id: I77897c2146d1b1318f966982ef0981c9221f69f7 PiperOrigin-RevId: 175159797
* Windows,JNI,logging: improve error messagesGravatar Laszlo Csomor2017-10-26
| | | | | | | | | | | | | | In this commit: - introduce the MakeErrorMessage function, which creates a structured error message with file and line information of the error's origin - update all error messages in the Windows JNI library - simplify GetLastErrorMessage to just convert an error code to string, without prepending a cause Change-Id: Ia8162bfdaee37d4b7ccb3a46d6c8a861b0a1bd94 PiperOrigin-RevId: 173402968
* Windows, jni: Don't close stdout/stderr in nativeWaitFor functionGravatar Yun Peng2017-10-24
| | | | | | | | | | | | | | | | | | | | | | | | These two close operations were added to work around #1708, but caused #2675. We found the root cause of the hanging problem in #1708 is a race condition when creating Windows processes: When Bazel trys to create two processes, one for a local command execution, one for starting the worker process. The worker process might accidentally inherits handles opened when creating the local command process, and it holds those handles as long as it lives. Therefore, ReadFile function hangs when handles for the write end of stdout/stderr pipes are released by the worker. The solution is to make Bazel native createProcess JNI function explicitly inheirts handles as needed, and use this function to start worker process. Related: http://support.microsoft.com/kb/315939 Fixed https://github.com/bazelbuild/bazel/issues/2675 Change-Id: I1c9b1ac3c9383ed2fd28ea92f528f19649693275 PiperOrigin-RevId: 173244832
* Windows,JNI: use wstrings onlyGravatar Laszlo Csomor2017-10-20
| | | | | | | | | | | | | | | | | | | | In this commit: - fix the Windows JNI library to only use UTF-16 strings Converting between multi-byte strings (UTF-8) and wstrings (UTF-16) always carries the risk of incorrectly handling the strings. It also takes time, even if not much. Not converting the strings but using the raw Java strings (which are in fact UTF-16 strings) simplifies the code and allows using non-ASCII paths (at least in the JNI module, even if Bazel as a whole doesn't support non-ASCII characters). Change-Id: I827fbe92a1bbefac049a1e34ac1738c965ed2e9c PiperOrigin-RevId: 172715277
* build_windows_jni: fix @cd callGravatar Laszlo Csomor2017-10-18
| | | | | | | | | | | | In cmd.exe it's not enough to `cd` into a directory to change the shell's current working directory: you also have to change to the right drive. Fixes https://github.com/bazelbuild/bazel/issues/3906 Change-Id: I4dd1a17e8b6b4a0db8fb7a56239ed78de3efae95 PiperOrigin-RevId: 172437822
* Windows,bootstrapping: fix build_windows_jni.shGravatar Laszlo Csomor2017-10-06
| | | | | | | | | | | | | | Also: - check as the first thing in compile.sh that we can locate the GNU coreutils, and remove the duplicate check for the same thing on Windows - check early in compile.sh that we can access python.exe Fixes https://github.com/bazelbuild/bazel/issues/3863 Change-Id: Ib48b405cf93eafd48e21b280bcbab4d45117c1d9 PiperOrigin-RevId: 171291435
* Harden AutoHandle.Gravatar Dmitry Lomov2017-08-23
| | | | | | | | Make 'handle' field private to ensure that AutoHandle'd handles are always closed. Change-Id: I0ff7069c1c02ac4c5d48ea9d83304a867e7ab524 PiperOrigin-RevId: 166163988
* Add build_windows_jni.sh backGravatar Yun Peng2017-08-10
| | | | | | | | | | src/main/native/windows/build_windows_jni.sh is still needed during Windows bootstrap at Building Bazel with Bazel step. Fixed https://github.com/bazelbuild/bazel/issues/3529 Change-Id: I42a1771e8c02a438b866725c98c7f2214620942a PiperOrigin-RevId: 164828380
* Using cc_binary to build windows_jni.dllGravatar Yun Peng2017-07-31
| | | | | | | Get rid of build_windows_jni.sh and the corresponding genrule. Change-Id: I89a199b61109f5687f8b500b60d284cae97f6457 PiperOrigin-RevId: 163679307
* Windows: check in the icon resource fileGravatar Laszlo Csomor2017-07-27
| | | | | | | | | | | | | | | | | | | | The icon resource is a simple object file, built by rc.exe, but rc.exe is part of the Windows Kit, not of Visual Studio, and we have no reliable way to locate it, so we can't reliably rebuild the icon resource from source. Rather than having a brittle genrule that may or may not find the resource compiler, thus may or may not successfully build the icon resource and thus fail the whole build for //src:bazel.exe, let's just use a prebuilt object file. In a subsequent commit I'll add a script that can rebuild this file. Change-Id: Ia1f31ca9e78378088f93c9db144a2b708d690893 PiperOrigin-RevId: 163332738
* Windows: Bazel now has an iconGravatar Laszlo Csomor2017-07-27
| | | | | Change-Id: I50a093d4ee1352d7e8958148fec5d577b5eaf00d PiperOrigin-RevId: 163316612
* Windows: clean up error reportingGravatar Laszlo Csomor2017-07-20
| | | | | | | | | | | | | | | | | | | In this commit: - remove blaze::PrintError in favor of blaze_util::PrintError - remove Ijar's PrintLastErrorMessage in favor of blaze_util::PrintError - use pdie every time path conversion fails, because that indicates a fatal error (bad user input for a path flag, or downright bug) - remove explicitly printing GetLastErrror; pdie and PrintError do it already - unify the pdie/PrintError message formats Fixes https://github.com/bazelbuild/bazel/issues/2935 Change-Id: I5feaf73885cab95c43a28c529ada6942e037b162 PiperOrigin-RevId: 162587490
* 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
* Windows, JNI: move around sourcesGravatar Laszlo Csomor2017-06-29
Move the Windows JNI C++ sources to a separate package and separate namespace. This no-op refactoring allows other build rules than Bazel's client library to depend on file I/O and/or JNI functionality. A follow-up commit will split the //src/main/native/windows:processes library into :jni-processes and :jni-file. Change-Id: I33c5f8ebd8961cc440db3b4a95ff78024d7c1d74 PiperOrigin-RevId: 160404298
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 11:36:54 +0000