aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/native
Commit message (Collapse)AuthorAge
* Windows,JNI: more tolerance for errorsGravatar Laszlo Csomor2018-07-24
| | | | | | | | | | | | | | | | | | | | | DeletePath and CreateJunction are now even more tolerant with errors, particularly the class of errors where access is denied. Also in this change: - remove DeletePathResult::kParentMissing, as this case is handled by CreateFileW's error handling later - do not error-check CreateDirectoryW; if failed, just proceed as if the directory already existed - print more debugging info where possible Change-Id: I1162dae2c6b7524f14d8892047f9eb51831470dd Closes #5611. Change-Id: I78fe6aed6d0b120815339c0923c8a903990921d9 PiperOrigin-RevId: 205796307
* Windows,JNI: graceful error-handlingGravatar Laszlo Csomor2018-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CreateJunction and DeletePath are now more resilient to errors: - CreateJunction opens the junction path to check its target requesting fewer rights and with greater sharing permission. This way it can check junction targets even if the junction name is opened by another process with no sharing. - DeletePath attempts to call FindFirstFileW if GetFileAttributesW fails with ERROR_ACCESS_DENIED. There's hardly any info about this error mode online, except for a code comment in the .NET CoreFX library. (See new code comments in this commit.) Also: - Change the error codes for DeletePath. - Wrap the DeletPath error codes in a struct for better readability. Fixes https://github.com/bazelbuild/bazel/issues/5433 Change-Id: I5b6e0f27b5b22c1cf00da90104495eda84178283 Closes #5590. Change-Id: I5b6e0f27b5b22c1cf00da90104495eda84178283 PiperOrigin-RevId: 204438994
* Windows,JNI: more robust nativeCreateJunctionGravatar Laszlo Csomor2018-07-09
| | | | | | | | | | | | | | | | | | | | | | | | Rewrite the CreateJunction function in the Windows JNI library. The new implementation's improvements: - succeeds if the junction already exists with the desired target; hopefully this will fix issue https://github.com/bazelbuild/bazel/issues/5433 - tolerant to concurrent filesystem modifications, e.g. if the junction's path suddenly disappears, the function reports the error correctly Fixes https://github.com/bazelbuild/bazel/issues/5433 Change-Id: I58a2314a00f6edaa7c36c35ba54616168b44eb7d Closes #5528. Change-Id: I9f5dc9237b70a433d0d8c2578a826de3d462d110 PiperOrigin-RevId: 203744515
* Windows,JNI: implement native DeletePath methodGravatar laszlocsomor2018-07-06
| | | | | | | | | | | | | | | | | | Implement a native DeletePath method that can delete files, directories, and junctions. The method should tolerate when concurrent processes delete the file. The new JNI function is more robust than Java IO file deletion function because it can also delete readonly files. See https://github.com/bazelbuild/bazel/issues/5513 Closes #5520. Change-Id: I21ea36dd64960b294e2b51600273bf4290ad7c0f PiperOrigin-RevId: 203448581
* Add parentheses to bool expr with && and ||Gravatar Loo Rong Jie2018-06-28
| | | | | | | | Boolean expression with *both* `&&` and `||` must use parentheses to prevent ambiguity. Closes #5475. PiperOrigin-RevId: 202445215
* Update FreeBSD JNI to support new attr_not_found parameter.Gravatar John Cater2018-02-22
| | | | | | | | | Fixes #4674. Tested: https://ci.bazel.build/blue/organizations/jenkins/CR%2Fbazel-tests/detail/bazel-tests/903/pipeline/ (FreeBSD tests pass, failures are unrelated) Change-Id: Ifc9c5be0cb4d7c877c64fc21632ae8a8c9582d33 PiperOrigin-RevId: 186651937
* Make getxattr not throw an exception when attribute does not exist on Mac.Gravatar ajmichael2018-02-09
| | | | | | | This matches the current behavior on Linux. When an extended attribute is not present on a file, getxattr on Linux returns ENODATA whereas getxattr on Mac returns ENOATTR. Previously, we were special casing ENODATA to not throw an exception but not ENOATTR. Now we treat them the same. RELNOTES: None PiperOrigin-RevId: 185157964
* Clean up Windows config_settingsGravatar Yun Peng2018-01-12
| | | | | | | | | | | | | | 1.Deleted config_setting for --cpu=x64_windows_msys, because we don't build Bazel with MSYS gcc anymore. 2.Deleted config_setting for --cpu=x64_windows_msvc, because it uses exactly the same toolchain as --cpu=x64_windows, it'll be removed in the future. This change reduces the complexity of our BUILD files and make them less confusing. Change-Id: I939831a6861413b0f745fb1be98aacd4fb780e0a PiperOrigin-RevId: 181751853
* isable_presubmitGravatar Googler2018-01-10
| | | | PiperOrigin-RevId: 181491528
* Save errno in unix_jni.cc stat when throwing exceptions.Gravatar tomlu2018-01-09
| | | | | | It's otherwise possible that we do other syscalls in between the original syscall and us reading the errno for use in the exception. PiperOrigin-RevId: 181367811
* Fix bug in unix_jni.cc that causes Path#exist to spuriously return true.Gravatar tomlu2018-01-09
| | | | | | | | We use errno to signal an error in the stat call that gets passed back to Java land. However, between the time we make the failed stat syscall and the time that we read the final value of errno we will very rarely make other syscalls in between, which will stomp the value of errno back to 0. This will get interpreted as "no error, the file exists" by the VFS. This bug has existed since 2009. Only a perturbation of the sequence of syscalls we make during startup has since caused the bug to surface. PiperOrigin-RevId: 181358035
* Add FileSystem#createDirectoryAndParents.Gravatar tomlu2017-12-21
| | | | | | | | A native implementation of this (instead of using FileSystemUtils, which can only use public interfaces) should be more efficient and more easy to make correct. In particular, it should allow removing FileSystemUtils#createDirectoriesAndParents, which has poor thread safety characteristics. The latter method has a lot of logic that forces certain unnatural atomicity guarantees on createDirectory, and it also has logic that is conditional on sub-string content of exception messages. PiperOrigin-RevId: 179819623
* 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
* Move bazel conditions into src/conditions.Gravatar tomlu2017-11-30
| | | | | | | This will enable an easier transition from checked-in BUILD files to ones generated by copybara. RELNOTES: None PiperOrigin-RevId: 177514519
* 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
* Clean up TODOs.Gravatar László Csomor2017-10-09
| | | | | | | | | | | | | | | | | | | In this commit: * buildenv.sh: restore its state to that as of commit 511c35b46cead500d4e76706e0a709e50995ceba * CommonCommandOptions.java: remove a deprecated no-op flag * WindowsPathFragment.java: implement an ASCII-only isLetter function, use that instead of Character.isLetter, because the latter returns true for some Unicode characters too * bazel_bootstrap_distfile_test: remove logging that we no longer need, since the bugfix for issue #3618 will be pushed to GitHub later today Change-Id: Ibda70219e974f0c47bc82addc647d8951f4bd701 PiperOrigin-RevId: 171498977
* 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
* Make source code of singlejar and ijar available from @bazel_tools. ,Gravatar Xin Gao2017-06-22
| | | | | | | | | | Please refer to patch set 9 and its CI run for usage and test results. In practice, users should create their own java_toolchain rule in their project's BUILD file, and set the two attributes like above instead of modifying //tools/jdk/BUILD. Change-Id: Ic880f243086b00a58d453a8139ba4c957fe54bc7 PiperOrigin-RevId: 159694649
* Bazel client, Windows: impl. client-level lockingGravatar laszlocsomor2017-04-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement blaze::AcquireLock and ReleaseLock. These methods implement the Bazel client-level locking, whose purpose is to detect concurrently running Bazel instances attempting to write to the same output directory. The Bazel server also detects this case (see BlazeCommandDispatcher) but the client needs to start the server first, meaning this cannot detect races between clients that are in the middle of installing. You can see this locking in effect if you run `bazel --output_user_root=/c/foo build src:bazel` in one terminal, then run `bazel --output_user_root=/c/foo help` in another but the same working directory. The second one will say "Another command is running." See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2647 RELNOTES: none PiperOrigin-RevId: 152919185
* Windows, JNI: non-zero exit code for terminationGravatar laszlocsomor2017-04-04
| | | | | | | | | | | | | | | | | | | Terminate processes and job objects with non-zero exit code. Zero was the most unfortunate exit code possible because it made the Java side believe that the process exited successfully. There's another bug in the Java side too where StandaloneSpawnStrategy ignores the thread's interruption state. I'll fix that in a separate change. Fixes https://github.com/bazelbuild/bazel/issues/2774 Change-Id: I01b3d95848cb04618395c9ef2fa0d1a406b25cca PiperOrigin-RevId: 152119343
* Windows JNI: make the builder .bat executable Gravatar László Csomor2017-03-23
| | | | | | | | | | Came up while working on https://github.com/bazelbuild/bazel/issues/2725 -- Change-Id: I923690642d0fc93dcdb5050837b5ddaaa2a1d494 Reviewed-on: https://cr.bazel.build/9469 PiperOrigin-RevId: 150880961 MOS_MIGRATED_REVID=150880961
* Make Bazel work with all MSVS 2017 editions Gravatar Alexander Chung2017-03-16
| | | | | | | | | | | | | Added support for Enterprise, Professional, and Community editions of Microsoft Visual Studio 2017. In the Community edition, the working directory changes after vcvarsall.bat is called. Not sure why. Closes #2658. -- Reviewed-on: https://github.com/bazelbuild/bazel/pull/2658 PiperOrigin-RevId: 150203876 MOS_MIGRATED_REVID=150203876
* Initialize the mutex in JNIEventsDiffAwareness Gravatar Julio Merino2017-03-07
| | | | | | | | | | | | | | | | | | | | | | | | pthread mutexes must be initialized with pthread_mutex_init and cleaned up with pthread_mutex_destroy. This seems to fix a race where poll() would access invalid array indexes on an array constructed based on the size of a shared list protected by the mutex. This is understandable because the mutex may not have been doing anything due to the lack of its proper initialization -- and, if so, I'm surprised the consequences were not more catastrophic. As with any race condition, it is hard to confirm that this fixes the observed problem, but I could trivially reproduce this issue earlier and now I cannot with this fix after tens of runs. See reproduction code in the referenced bug for details on how to expose the issue. Fixes #1676. -- Change-Id: Ia5a4a8f12da7c3780f33266b9922eeba7645b3a4 Reviewed-on: https://cr.bazel.build/9230 PiperOrigin-RevId: 149414125 MOS_MIGRATED_REVID=149414125
* Windows, JNI: allow empty cwd for processesGravatar Laszlo Csomor2017-03-07
| | | | | | | | | | | | | | | | More specifically, change windows_util.AsShortPath to accept empty inputs, as well as paths with forward slashes. Also output more accurate error messages for bad input paths than before. This fixes //src/test/java/com/google/devtools/build/lib:windows-tests but not //src/test/java/com/google/devtools/build/lib:standalone-tests -- PiperOrigin-RevId: 149399449 MOS_MIGRATED_REVID=149399449
* Windows, JNI: shorten the cwd for CreateProcessGravatar Laszlo Csomor2017-03-06
| | | | | | | | | | | | | | The hard limit for SetCurrentDirectory{A,W} is MAX_PATH-1, even with UNC prefix, therefore a process' cwd may also not be longer than that. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2406 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 149290147 MOS_MIGRATED_REVID=149290147
* Move FileAccessException to the vfs packageGravatar Ulf Adams2017-02-17
| | | | | | | | | | | | | | It was previously in unix, but also used from non-unix file systems, which means it's not actually unix-specific. This is in preparation for splitting compilation of the unix and windows file systems into separate libraries. That improves layering and reduces compile times - note that Bazel already injects the vfs into its lower layers, which should only rely on the normal vfs APIs, not on anything platform-specific. -- PiperOrigin-RevId: 147829659 MOS_MIGRATED_REVID=147829659
* 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
* Bazel client, JNI, Windows: impl. CreateJunction Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Implement a CreateJunction function in the Windows JNI library. Also move a bit of code from file_windows to the JNI library, where it is (also) needed. This implementation is an improved version of `blaze_util::SymlinkDirectories` in blaze_util_windows: this version handles Windows paths as `name` and `target`, and performs more validation (e.g. on the length of `target`), plus has more comments explaining the logic. In a subsequent change I'll start using this new function in blaze_util_windows. This method will also be helpful in tests: we will no longer have to shell out to mklink. See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: I7e9b085fdc2ba47be83da5319bded02bd323e71b Reviewed-on: https://cr.bazel.build/8892 PiperOrigin-RevId: 147585207 MOS_MIGRATED_REVID=147585207
* Make Bazel work with Visual Studio 2017 Gravatar Yun Peng2017-02-14
| | | | | | | | | | | | | | | Now Bazel can detect MSVC from Visual Studio 2017 or Visual C++ build tools 2017. Also modified build_windows_jni.sh to make it work with VS 2017. Fixed: https://github.com/bazelbuild/bazel/issues/2440 -- Change-Id: I4afbce809ff74634f32fab87efe5e7f0b3f60c95 Reviewed-on: https://cr.bazel.build/8890 PiperOrigin-RevId: 147467993 MOS_MIGRATED_REVID=147467993
* Windows JNI, refactor: move OpenDirectory to JNIGravatar Laszlo Csomor2017-02-14
| | | | | | | | | | | | Move the OpenDirectory helper method into the JNI library. We'll need it there; a subsequent change will make use of it there. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 147448792 MOS_MIGRATED_REVID=147448792
* Bazel client, Windows, tests: `rm -rf TEST_TMPDIR`Gravatar Laszlo Csomor2017-02-10
| | | | | | | | | | | | Add test helpers to recursively delete the TEST_TMPDIR in the TearDown method of tests, to ensure each test sees a fresh temp directory. Also add tests for these test helpers. -- PiperOrigin-RevId: 147135561 MOS_MIGRATED_REVID=147135561
* Bazel client, Windows: use more of AutoHandleGravatar Laszlo Csomor2017-02-09
| | | | | | -- PiperOrigin-RevId: 147008328 MOS_MIGRATED_REVID=147008328
* Add quotes to improve space supportGravatar Alexander Chung2017-02-07
| | | | | | | | | | | These changes addresses issues where Windows users have a space in their username. Allows the default output_base path to be used. Closes #2491. -- Reviewed-on: https://github.com/bazelbuild/bazel/pull/2491 PiperOrigin-RevId: 146773331 MOS_MIGRATED_REVID=146773331
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-07 14:39:58 +0000