aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/cpp
Commit message (Collapse)AuthorAge
...
* Use a CommandLine struct to store the command line parsed by the ↵Gravatar lpino2017-07-11
| | | | | | | | OptionProcessor. This replaces the startup_args_, command_ and command_argument members to allow a more consistent representation of the command line throughout the class. PiperOrigin-RevId: 161408010
* Raise the maximum number of processes and open files to their maximum.Gravatar jmmv2017-07-11
| | | | | | | | | | | | | | | | | | | Under macOS, the default soft resource limits for open files and concurrent processes are pretty low, but their corresponding hard defaults are reasonable. Because the soft limits are low, Bazel sometimes fails during large builds -- not because of Bazel itself, but because the executed actions do "too much work" or because the --jobs setting was high enough to cause all parallel tasks to exceed the limits. Instead of trying to fix the actions themselves, start by trying to raise the system limits as a best-effort operation. And, given that this code is fairly portable, try to do it on all POSIX systems and not just macOS. Note that, for non-macOS systems, this might still not do what's promised in all circumstances because I'm currently only implementing GetExplicitSystemLimit on macOS. RELNOTES: None. PiperOrigin-RevId: 161401482
* Open source {workspace_layout,startup_options,option_processor}_test.Gravatar lpino2017-07-05
| | | | | | Additionally rewrite the option_processor_test to make it more flexible. PiperOrigin-RevId: 160958736
* cleanup {get,set,unset}env() functions callsGravatar Thiago Farina2017-07-05
| | | | | | | | Instead, let's reuse the cross-platform {Get,Set,Unset}Env() functions when possible. Change-Id: I40b4ff09c66fe238d5b3d70e49f91705cea64b0c PiperOrigin-RevId: 160870850
* Create the StartupFlag class and use it instead of plain list of strings.Gravatar lpino2017-06-30
| | | | | | | | Additionally, add a warning note for developers who wish to delete startup options: they first need to deprecate the flag and once it's a no-op for a sufficient amount of time then they can delete it from the list of valid options. PiperOrigin-RevId: 160546248
* Internal changeGravatar Googler2017-06-29
| | | | PiperOrigin-RevId: 160506627
* 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
* Internal changeGravatar Googler2017-06-28
| | | | PiperOrigin-RevId: 160373741
* cpp: add unit tests for MakeAbsolute()Gravatar Thiago Farina2017-06-28
| | | | | | | | | | | While fixing its TODO. Tested with the following command line: $ bazel test //src/test/cpp/... Change-Id: I62d5d0f19b7242fd2eeae7901e1e236c782ebfb5 PiperOrigin-RevId: 160270960
* Make Bazel build without --cpu=x64_windows_msvcGravatar Yun Peng2017-05-30
| | | | | | | | | | | | | | | | After this change, with a Bazel having MSVC as default toolchain, the command to build a MSVC Bazel on Windows is simply: bazel build //src:bazel although bazel build --cpu=x64_windows_msvc //src:bazel is still supported. And the command to build a MSYS Bazel on Windows is: bazel build --cpu=x64_windows_msys //src:bazel Also made //src/test/cpp:blaze_util_test pass without --cpu=x64_windows_msvc Change-Id: Iaf37513c778768d06fb5700442d5229a5f348964 PiperOrigin-RevId: 157446905
* Add a custom single-line formatter for java.log.Gravatar schmitt2017-04-13
| | | | | | | | This logger makes it easier to parse log statements and is now enabled for Bazel's java.log. RELNOTES[INC]: Bazel now prints logs in single lines to java.log PiperOrigin-RevId: 152954337
* Make Search{Unary,Nullary}Option skip the rest of the args if "--" is found.Gravatar Luis Fernando Pino Duque2017-03-27
| | | | | | -- PiperOrigin-RevId: 151145409 MOS_MIGRATED_REVID=151145409
* Bazel client, Windows: fix MSYS root computation Gravatar László Csomor2017-03-23
| | | | | | | | | | | | | | Make it more robust: it now works with Cygwin too, e.g. BAZEL_SH=c:/cygwin64/bin/bash.exe See https://github.com/bazelbuild/bazel/issues/2725 Related to https://github.com/bazelbuild/bazel/issues/2447 -- Change-Id: I911f09acd3e39c7cd0fe0750774fa0a900ffd844 Reviewed-on: https://cr.bazel.build/9510 PiperOrigin-RevId: 150885982 MOS_MIGRATED_REVID=150885982
* Bazel client, Windows: support "d:/" output rootGravatar Laszlo Csomor2017-03-16
| | | | | | | | | | | | | Support drive roots as --output_user_root values, so "d:\" and "d:/" will now work. However "d:" doesn't work yet because that's shorthand for the current working directory on "D:". See https://github.com/bazelbuild/bazel/issues/2683 -- PiperOrigin-RevId: 150203657 MOS_MIGRATED_REVID=150203657
* Make Bazel build with MSVC-default-toolchain Bazel Gravatar Yun Peng2017-03-08
| | | | | | | | | | | | | After this change, a msys bazel can be built with a MSVC-default Bazel by adding --cpu=x64_windows_msys --host=x64_windows_msys See https://github.com/bazelbuild/bazel/issues/2627 -- Change-Id: Iaa82bf4dd911c5740b98d3b2739dfccca6203f79 Reviewed-on: https://cr.bazel.build/9293 PiperOrigin-RevId: 149532274 MOS_MIGRATED_REVID=149532274
* Bazel client, Windows: fix ReadFile("/dev/null")Gravatar Laszlo Csomor2017-03-06
| | | | | | | | | | | Mimic read(2) behavior when reading from /dev/null and always successfully read 0 bytes. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 149286494 MOS_MIGRATED_REVID=149286494
* Bazel client, Windows: fix AsShortWindowsPathGravatar Laszlo Csomor2017-03-06
| | | | | | | | | | This method now works for non-existent paths too. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 149284633 MOS_MIGRATED_REVID=149284633
* Bazel client: do not use `errno`.Gravatar Laszlo Csomor2017-03-02
| | | | | | | | | | | | | | | Do not use `errno` in platform-independent code, because Windows API functions don't set it. This change abstracts away error handling and the functions whose `errno` result we care about, will set an input error variable. Fixes https://github.com/bazelbuild/bazel/issues/2506 -- PiperOrigin-RevId: 148977873 MOS_MIGRATED_REVID=148977873
* Bazel client: simplify {Read,Write}File semanticsGravatar Laszlo Csomor2017-03-01
| | | | | | | | | | | | | | | | Introduce a platform-specific file handle type (HANDLE on Windows, int on Linux/Darwin/FreeBSD) so we can get rid of the read_func and write_func functions, since they are always the same everywhere. Also include file_platform.h in file.h, since they are logically the same file (file_platform.h is just the platform-specific part of file.h). -- PiperOrigin-RevId: 148892736 MOS_MIGRATED_REVID=148892736
* Bazel client: add new ReadFile/WriteFile variantsGravatar Laszlo Csomor2017-02-27
| | | | | | | | | | | | | Instead of writing from / reading to a string, these variants take a buffer and a size. These methods will be used from ijar. See https://github.com/bazelbuild/bazel/issues/2157 -- PiperOrigin-RevId: 148635487 MOS_MIGRATED_REVID=148635487
* Bazel client, Windows: impl. ForEachDirectoryEntry Gravatar Laszlo Csomor2017-02-17
| | | | | | | | | | | | | | | | | | | | This is the last function we needed from file_posix for MSYS, so now we can remove that from the compilation. Fixes https://github.com/bazelbuild/bazel/issues/2386 The problem originally was that I used CloseHandle to close the HANDLE, instead of using FindClose, so we were holding on to open directory HANDLEs, so we couldn't rename the installation directory. See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: If6c1b3c99cf386d82e829dbee2323e6bce5f6b46 Reviewed-on: https://cr.bazel.build/8952 PiperOrigin-RevId: 147734165 MOS_MIGRATED_REVID=147734165
* Bazel client, Windows: implement MakeCanonical Gravatar Laszlo Csomor2017-02-16
| | | | | | | | | | See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: I27a97881e3e19cbb7913e1248a24e9e631bc4f40 Reviewed-on: https://cr.bazel.build/8951 PiperOrigin-RevId: 147719277 MOS_MIGRATED_REVID=147719277
* Bazel client: refactors, small bugfixes Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | | | | | | | In this change: * Fix pdie and PrintError to acquire the last error string as the first thing the method does, otherwise we may display an error coming from pdie's/PrintError's own logic * Auto-close file handles in file_test in order to avoid leaking them in case an assertion fails (which means an early return from the function) -- Change-Id: Ia4392b42cbc93b931dcee76993db0ad264d0c147 Reviewed-on: https://cr.bazel.build/8932 PiperOrigin-RevId: 147610527 MOS_MIGRATED_REVID=147610527
* Bazel client, Windows, tests: use CreateJuction Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | Use the JNI library's CreateJuction in file_windows_test. See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: I4ef1536d43691fe7a2ae3ee457064d4e8f4ac6d7 Reviewed-on: https://cr.bazel.build/8895 PiperOrigin-RevId: 147594365 MOS_MIGRATED_REVID=147594365
* Bazel client, Windows, tests: remove cleanup code Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | The TearDown method clears up after tests, so manual cleanup is unnecessary. See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: Idf5d2b2bf012774171f1868d1341a7952015c35f Reviewed-on: https://cr.bazel.build/8894 PiperOrigin-RevId: 147591032 MOS_MIGRATED_REVID=147591032
* 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
* 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: retry moving install base directoryGravatar Laszlo Csomor2017-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | Do not give up immediately if renaming/moving the install base directory fails, wait and retry instead. This is necessary because on Windows the directory we just created and populated with the extracted embedded binaries may still be scanned by the antivirus, so there are open file handles in it so it cannot be renamed. This new logic ensures the AV has enough time to scan all files, close the handles, letting us successfully rename the directory. Fixes the occasional "install base directory cannot be renamed in place" error messages on Windows. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 146899919 MOS_MIGRATED_REVID=146899919
* Parameterize the Java logging formatter class.Gravatar Julio Merino2017-02-06
| | | | | | | | | | Allow subclasses of StartupOptions to override the formatter passed to the Java logging configuration. This is to allow us to override this value internally for Blaze in an attempt to homogenize things. -- PiperOrigin-RevId: 146668430 MOS_MIGRATED_REVID=146668430
* Fix //src/test/cpp/util:logging_test on Windows Gravatar László Csomor2017-01-30
| | | | | | | | | | | | | | | Set $TMP to $TEST_TMPDIR, so that the CaptureStderr can safely call SetTempPathA and not get C:\Windows\ back as a result, which is unfortunately read-only. See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: If63cb028f677d9a0d9597f83afc9e08f2e5d2529 Reviewed-on: https://cr.bazel.build/8494 PiperOrigin-RevId: 145961529 MOS_MIGRATED_REVID=145961529
* Rollback of commit d5527469ca629f806a7576783289cc0613bf418b.Gravatar Laszlo Csomor2017-01-23
| | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks Bazel-Install-Trigger on CI. *** Original change description *** Bazel client, Windows: impl. ForEachDirectoryEntry Implement ForEachDirectoryEntry on Windows using FindFirstFileW / FindNextFileW. Supports long paths and traversing junctions. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 145282158 MOS_MIGRATED_REVID=145282158
* Bazel client, Windows: impl. ForEachDirectoryEntryGravatar Laszlo Csomor2017-01-20
| | | | | | | | | | | | | | Implement ForEachDirectoryEntry on Windows using FindFirstFileW / FindNextFileW. Supports long paths and traversing junctions. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 145062749 MOS_MIGRATED_REVID=145062749
* Bazel client: abstract away mtime handlingGravatar Laszlo Csomor2017-01-19
| | | | | | | | | | | | | | | | | | | | | Create an IFileMtime class and platform-specific implementations to deal with mtime handling. Since epochs and time granularity vary from platform to platform, and we only care about setting a file's/directory's mtime to the current time or to a future time plus querying whether something is in the future, we can easily create an interface for these operations and that's exactly what IFileMtime is. Implement PosixFileMtime and WindowsFileMtime. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144956966 MOS_MIGRATED_REVID=144956966
* Bazel client, Windows: use CreateFileWGravatar Laszlo Csomor2017-01-18
| | | | | | | | | | | | | | | | | | | | | | Use CreateFileW in blaze_util_windows.cc when opening the "jvm.out" file. This allows supporting long paths. Also use AsWindowsPathWithUncPrefix instead of just AsWindowsPath plus manually adding the UNC prefix. Also fix a compilation error in file_windows_test.cc, I'm surprised the CI system didn't catch this, maybe we aren't running this test there. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144813245 MOS_MIGRATED_REVID=144813245
* Bazel client, Windows: implement envvar handlingGravatar Laszlo Csomor2017-01-18
| | | | | | | | | | | Implement GetEnv, SetEnv, UnsetEnv, and use it in some locations, plus add some tests. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144808435 MOS_MIGRATED_REVID=144808435
* Bazel client, Windows: implement CanAccess methodsGravatar Laszlo Csomor2017-01-12
| | | | | | | | See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144321891 MOS_MIGRATED_REVID=144321891
* Bazel client, Windows: implement MakeDirectoriesGravatar Laszlo Csomor2017-01-12
| | | | | | | | | See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/1744 -- PiperOrigin-RevId: 144313301 MOS_MIGRATED_REVID=144313301
* Bazel client, Windows: implement WriteFileGravatar Laszlo Csomor2017-01-12
| | | | | | | | See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144218095 MOS_MIGRATED_REVID=144218095
* Bazel client, Windows: support /dev/nullGravatar Laszlo Csomor2017-01-11
| | | | | | | | | | | | | | | | | Support passing /dev/null and NUL as flag values for flags like --bazelrc. In particular, special-case these paths in methods like blaze_util::ReadFile, blaze_util::IsDirectory, etc. Fixes https://github.com/bazelbuild/bazel/issues/2354 RELNOTES[NEW]: Windows: "/dev/null" is now a supported path, e.g. --bazelrc=/dev/null now works -- PiperOrigin-RevId: 144195994 MOS_MIGRATED_REVID=144195994
* Bazel client, Windows: implement UnlinkPathGravatar Laszlo Csomor2017-01-11
| | | | | | | | | | | | | | | | This was committed and rolled back twice, once because I forgot to update file_posix.cc, and again because the roll-forward was somehow only partial. This is a clean attempt at submitting the same thing again. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144179954 MOS_MIGRATED_REVID=144179954
* Bazel client: split CanAccess to specific methodsGravatar Laszlo Csomor2017-01-11
| | | | | | | | | | | | | | The new methods (CanReadFile, CanExecuteFile, CanAccessDirectory) are a lot easier to implement on Windows than a generic CanAccess. On POSIX these methods are just a wrapper around the now static-visible CanAccess(). See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144176710 MOS_MIGRATED_REVID=144176710
* Rollback of commit e1f8bbc1fe1d0a22736597dbd029155b01718b94.Gravatar Laszlo Csomor2017-01-10
| | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Bad rollback, was only partial. *** Original change description *** Automated [] rollback of commit 9a13899b1492738f8d1a9118cebc9ef9d90c6b34. *** Reason for rollback *** Fixed the problem with the CL. *** Original change description *** Bazel client, Windows: implement UnlinkPath See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144115263 MOS_MIGRATED_REVID=144115263
* Rollback of commit 9a13899b1492738f8d1a9118cebc9ef9d90c6b34.Gravatar Laszlo Csomor2017-01-10
| | | | | | | | | | | | | | | | *** Reason for rollback *** Fixed the problem with the CL. *** Original change description *** Bazel client, Windows: implement UnlinkPath See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144087552 MOS_MIGRATED_REVID=144087552
* Bazel client, Windows: implement IsDirectoryGravatar Laszlo Csomor2017-01-10
| | | | | | | | See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144084379 MOS_MIGRATED_REVID=144084379
* Rollback of commit 9a13899b1492738f8d1a9118cebc9ef9d90c6b34.Gravatar Marcel Hlopko2017-01-10
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks windows: bazel-out/local-fastbuild/bin/src/main/cpp/util/libfile.a(file_windows.o):file_windows.cc:(.text+0x11e2): multiple definition of `blaze_util::UnlinkPath(std::string const&)' bazel-out/local-fastbuild/bin/src/main/cpp/util/libfile.a(file_posix.o):file_posix.cc:(.text+0x3ff): first defined here *** Original change description *** Bazel client, Windows: implement UnlinkPath See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144082937 MOS_MIGRATED_REVID=144082937
* Bazel client, Windows: implement UnlinkPathGravatar Laszlo Csomor2017-01-10
| | | | | | | | See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144073888 MOS_MIGRATED_REVID=144073888
* Windows: implement and use AsShortWindowsPathGravatar Laszlo Csomor2017-01-10
| | | | | | | | | | | | | | | | | | Because CreateProcessW doesn't support long paths, not even with the "\\?\" prefix [1], we need to convert long paths to short ones to spawn processes. This change implements the corresponding function and uses it in blaze_util_windows. [1] https://github.com/bazelbuild/bazel/issues/2181#issuecomment-270696173 See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144062404 MOS_MIGRATED_REVID=144062404
* Bazel client: move NormalizePath to Windows codeGravatar Laszlo Csomor2017-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | This method was only used by the Windows-specific code so move it there and adapt it to Windows paths. Update AsWindowsPath to normalize its output: this is necessary because AsWindowsPath's output is a widechar path string which we often prefix with the UNC prefix, but such paths must be normalized (the kernel won't do it if the path has an UNC prefix). Finally, add an AsWindowsPathWithUncPrefix method which does what the name suggests: converts the path to Windows path, makes it absolute, and adds the UNC prefix if necessary. (This is a very common operation when calling WinAPI functions and we'll use it a lot in subsequent changes.) See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144060297 MOS_MIGRATED_REVID=144060297
* Bazel client: implement PathExists on WindowsGravatar Laszlo Csomor2017-01-05
| | | | | | | | | | | | | | | | | | | | Checking if a path exists is surprisingly hard on Windows. The most convenient API functions are PathFileExists and GetFileAttributes but neither of them follows junctions. To check if a junction is dangling, we have to resolve it all the way. This change adds a JunctionResolver class to file_windows, which can resolve junctions (if they aren't dangling) and non-junctions (in this case just checks their existence). See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 143645274 MOS_MIGRATED_REVID=143645274
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 06:00:29 +0000