aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/cpp
Commit message (Collapse)AuthorAge
* Add more detailed reporting of the differences between startup options.Gravatar skainswo2018-08-10
| | | | | | | This changes the logging logic slightly to support diffing startup options between different runs that have different numbers of args. RELNOTES: Add more detailed reporting of the differences between startup options. PiperOrigin-RevId: 208239665
* Windows: do not look for Git BashGravatar Laszlo Csomor2018-08-08
| | | | | | | | | | | | | Fixes https://github.com/bazelbuild/bazel/issues/5751 RELNOTES[INC]: Windows: when BAZEL_SH envvar is not defined and Bazel searches for a suitable bash.exe, Bazel will no longer look for Git Bash and no longer recommend installing it as a Bash implementation. See issue #5751. Change-Id: I7350b1dd5c0a3777525956da6d620174fc6935ee Closes #5752. Change-Id: I7350b1dd5c0a3777525956da6d620174fc6935ee PiperOrigin-RevId: 207891008
* Add a option to disable idle gc.Gravatar Benjamin Peterson2018-08-08
| | | | | | | | | | | | | | | If a Bazel server is idle for 10 seconds, it unconditionally triggers a full-scale Java GC via System.gc(). This behavior doesn't have clear benefits and causes Bazel to steal resources from whatever the user does after invoking Bazel. This CL adds a startup option, --idle_server_tasks, to toggle the idle GC behavior. Also, add some logging for when idle GC is enabled, so it's easier to evaluate its effects. Example of logging: ``` 180718 17:43:04.609:I 247 [com.google.devtools.build.lib.server.IdleServerTasks.lambda$idle$0] [Idle GC] used: 157MB -> 15MB, committed: 421MB -> 422MB ``` Fixes https://github.com/bazelbuild/bazel/issues/5589. Closes #5628. PiperOrigin-RevId: 207869996
* Automatic code cleanup.Gravatar Googler2018-08-05
| | | | PiperOrigin-RevId: 207492223
* Change the list of rc files accepted.Gravatar ccalvarin2018-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The old list was, in order: - %workspace%/tools/bazel.rc (unless --nomaster_bazelrc) - %binary_dir%/bazel.bazelrc (unless --nomaster_bazelrc) - system rc, /etc/bazel.bazelrc or in %ProgramData% for Windows (unless --nomaster_bazelrc) - the first of the following gets called the "user" bazelrc - path passed by flag --bazelrc - %workspace%/.bazelrc - $HOME/.bazelrc The new list is hopefully a bit more consistent, as: - system rc (unless --nosystem_rc) - workspace, %workspace%/.bazelrc (unless --noworkspace_rc) - user, $HOME/.bazelrc (unless --nohome_rc) - command-line provided, passed as --bazelrc or nothing if the flag is absent. This list removes two less than useful locations, duplication in the Workspace directory, and the rc next to the bazel binary. This location made sense at Google but is generally nonsensical elsewhere so we are removing it. It also stops the user local rc file from being overriden by passing in a custom file in --bazelrc. In both old and new, --ignore_all_rc_files disables all of the above. For a transition period, any file that you would have loaded but was not read will cause a WARNING to be printed. If you want the old file to still be read without moving its location, you can always import it into one of the new standard locations, or create a symlink. Closes #4502, except for cleanup to remove the warning after a transition period of 1 Bazel version has passed. RELNOTES[INC]: New bazelrc file list. PiperOrigin-RevId: 207189212
* Add a normal startup-option for setting the digest function.Gravatar ccalvarin2018-08-01
| | | | | | | | | We continue to support the jvm property -Dbazel.DigestFunction, for backwards compatibility, but this will go away. The startup-option is marked experimental for now as we iron out issues. (note: leaving this out of release notes until the experimental tag is removed) As part of this refactor, the default constructor calls for FileSystem and derived classes will now use this default. This should remove the need for constructors that accept custom hash functions. RELNOTES: None. PiperOrigin-RevId: 207035217
* Make sure that user-level log messages are not lost in a buffer if debugGravatar ccalvarin2018-08-01
| | | | | | | | | | | logging is turned off. WARNINGs, ERRORs, and simple USER messages get printed to stderr when debug logging is disabled, which it is by default. However, before this change, these were lost if they were sent to BAZEL_LOG before Bazel knew whether or not debug logging was requested. This fixes that by maintaining separate buffers, and dumping only the appropriate one to stderr once we know whether or not it is wanted. Maintaining the separate buffer also allows for it to be easy to, in the future, allow logging to multiple places, if we are logging details to a file and user-level details to stderr, for example. RELNOTES: None. PiperOrigin-RevId: 206960686
* Add a --server_javabase startup option as an alias for the LHS --host_javabaseGravatar cushon2018-07-25
| | | | | | | | | | to avoid confusion between the LHS and RHS host_javabases. The LHS --host_javabase option should be considered deprecated and will eventually be removed. RELNOTES: Rename the startup flag --host_javabase to --server_javabase to avoid confusion with the build flag --host_javabase PiperOrigin-RevId: 206015757
* Fix block_for_lock.Gravatar ccalvarin2018-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | On two fronts: First, it should follow standard command line semantics. Second, it should work as intended: --noblock_for_lock means the client will not wait for another command to finish, but will exit eagerly. It can be useful for preventing hanging in applications that are non-interactively calling bazel. It should have standard startup-option semantics: the default value is accepted as a no-op or can be provided to override a previous value. The next issue involves 2 different locks - the client lock, and the server-side command lock. This duality exists because we would like, one day, to be able to run certain commands, like info or help, at the same time, so multiple commands would need specialized locks that allow some duality but blocks others. This can only be done at the server level, so as soon as the client gets the "we're connected" grpc message from the server, it releases the client lock and lets the server manage multiple requests. There are basically 3 possible states that are relevant to this option: 1) no other client is active, so no one holds the client lock or the command lock - the server can be used, shutdown or started as needed. - no blocking, but no need to block, either, so we're safe 2) another client (client1) holds the lock, but it is currently using a server that we want to reuse. If client1 still holds the client lock, we fail fast. Same thing if client1 is holding the server-side lock: we will exit gracefully when the BlazeCommandDispatcher responds with a failure. 3) client1 holds the lock but its server cannot be reused. (batch clients also fall into this category, as there is no server to reuse - but in this case, the client lock is still in play). However, for server mode, this is broken - the following happens: - Server is occupied with client1's request, holds the command lock - client2 wants to restart the server, so sends the old server a "shutdown" command - the BlazeCommandDispatcher says - nuh-uh, this is busy, and you said you didn't want to wait for the lock - client2 absorbs this response - waits (blocks...) - for a minute - then force shuts-down the old server. So we had 2 problems - we block, and we shutdown a server that we truly intended to keep going. Now, if the server responds saying another action is using it, the client will exit correctly, and leave the old server to do its thing. RELNOTES: None. PiperOrigin-RevId: 205671817
* blaze.cc: add missing fflush(3) before execve(2)Gravatar Klaus Aehlig2018-07-23
| | | | | | | | | | When calling `bazel run` the command itself is executed by the client. As an execve(2) replaces the program image, including all buffered IO, flush all streams first. This will ensure that the "Running command line" message is actually printed. Change-Id: Ie18185bac4ed82a2725c75f97d3c64bd3003690b PiperOrigin-RevId: 205652760
* jdk: use parallel old gc and disable compact stringsGravatar buchgr2018-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When switching to JDK9 we regressed on java build performance by about ~30%. We found that when using parallel gc instead of G1 and disabling compact strings for JavaBuilder, the java build performance is "only" 10% slower. We additionally found JDK9 to have a significantly higher startup time. This impacts the performance of tools like javac and tubine and we believe that this accounts for most of the remaining overhead that can't be explained by disabling G1 and compact strings. java8 -version: 80ms java9 -version: 140ms java10 -version: 110ms Additionally, we found that the number of modules shipped with the JDK have a direct effect on the startup time. When building Java 10 with only the 9 modules required by Bazel we find that the startup time reduces to 80ms (from 110ms) which is on par with Java 8. We thus expect the regression to be fixed by a future migration to Java 10, which should be done in one of the next Bazel releases. == Some benchmark results == https://github.com/google/protobuf $ bazel build :protobuf_java Bazel 0.15.2: 4.2s Bazel 0.16.0-rc2: 5.2s This Change: 4.2s https://github.com/jin/android-projects/tree/master/java_only $ bazel build :module0 Bazel 0.15.2: 8.2s Bazel 0.16.0-rc2: 11.5s This Change: 9.1s RELNOTES: None PiperOrigin-RevId: 205647957
* Fix race condition between server startup and command port reading.Gravatar twerth2018-07-18
| | | | | RELNOTES: None PiperOrigin-RevId: 205079775
* Windows,Bazel client: multithreaded file writingGravatar Laszlo Csomor2018-07-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Bazel client on Windows now writes extracted binaries to disk in parallel. On all other systems it writes them serially (as before). This change makes blaze.cc:ActuallyExtractData() about 3x faster when using a HDD. (In previous experiments I saw no speedup with multi-threaded writing on machines with an SSD.) The Windows-specific code uses the native Threadpool API of Windows, creating a pool of at least 8 and at most 16 threads. (This seems to be a good balance between speed and thread count.) The OS manages everything about the pool; Bazel submits callbacks and the pool executes them asynchronously. blaze.cc:ActuallyExtractData() speed, before: - Windows: 6.48s (avg) / 6.38s (median) - Linux (Debian): 4.78s (avg) / 4.79s (median) blaze.cc:ActuallyExtractData() speed, after: - Windows (8-16 threads): 2.05s (avg) / 2.01s (md) - Windows (1 thread): 5.77s (avg) / 5.74s (median) See https://github.com/bazelbuild/bazel/issues/5444 Change-Id: I7211f3d28eb8b9837352c16ff8df0411d5a9ebe1 Closes #5600. Change-Id: I7a74d62a563c92948a4dfa8ad5ac83eae018db10 PiperOrigin-RevId: 204891217
* Automatic ClangTidyReadability code cleanup.Gravatar Googler2018-07-12
| | | | PiperOrigin-RevId: 204254234
* 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
* blaze_util_freebsd.cc: include path.h explicitlyGravatar Klaus Aehlig2018-07-06
| | | | | | | | | | | ...as this file uses blaze_util::JoinPath. Apparently, until recently, that header file was pulled in indirectly, so that this wasn't detected until now. Nevertheless, the header files for functions used directly should also be included explicitly anyway. Change-Id: Id181480c6ec7fd146ce8b7b00980319f13c3f518 PiperOrigin-RevId: 203445044
* blaze_util_posix.cc: fix order of #defineGravatar Klaus Aehlig2018-07-05
| | | | | | | | | | On some systems (including some versions of FreeBSD) it is a requirement that _WITH_DPRINTF be defined for <stdio.h> to provide the appropriate header for dprintf(3). Therefore, the respective #define has to come before any #include as those might pull is <stdio.h>. Change-Id: I25d55c9c7c0912e8619faf774d2e09f9af9a6a53 PiperOrigin-RevId: 203351202
* Use const char a[] if sizeof is used to get lengthGravatar Loo Rong Jie2018-07-02
| | | | | | | | | | | | `memcmp(msys_display_name, value, sizeof(msys_display_name)` try to get length of `msys_display_name` with `sizeof`, but `msys_display_name` is declared as `const char*` pointer, so `sizeof` will return the size of pointer (8-bytes) instead of actual length of string. Declare string as `const char msys_display_name[]` will fix this. Found by Clang's `-Wsizeof-pointer-memaccess`. /cc @dslomov Closes #5476. PiperOrigin-RevId: 202903566
* Automatic ClangTidyReadability code cleanup.Gravatar Googler2018-06-29
| | | | PiperOrigin-RevId: 202644968
* Bazel,client: actually cache directory creationsGravatar Laszlo Csomor2018-06-27
| | | | | | | | | | | | | | | | | | | | Commit https://github.com/bazelbuild/bazel/commit/f5043d6831ea1c266104363b4e8911eb97f96fbc was incorrect in that it cached the file names, not the directory names. This commit fixes that. I verified that the number of calls to ExtractBlazeZipProcessor::Process is greater than the calls to MakeDirectories within (1038 vs. 172 on Linux). See https://github.com/bazelbuild/bazel/issues/5444 Change-Id: I314bdc9337c9782a5ceaed7aac785a552b222b1f Closes #5484. Change-Id: I314bdc9337c9782a5ceaed7aac785a552b222b1f PiperOrigin-RevId: 202314400
* Bazel client: add a simple profilerGravatar Laszlo Csomor2018-06-27
| | | | | | | | | | | | | | | | | | | | | | | | Add a simple profiler that can measure function call counts and durations, and report statistics by printing to stderr. Motivation: I recently needed a profiler for PR #5445 and PR #5448, so I'm adding the polished code now. Usage: 1. depend on //src/main/cpp/util:profiler 2. use StopWatch, Task, and ScopedTask objects as shown in profiler.h's class documentation See https://github.com/bazelbuild/bazel/issues/5444 Change-Id: I43f0afd124b486c694f451e8455a66ffca8137b6 Closes #5461. Change-Id: I43f0afd124b486c694f451e8455a66ffca8137b6 PiperOrigin-RevId: 202314319
* Windows: Native launcher now works with unicode.Gravatar Yun Peng2018-06-25
| | | | | | | | | | | | | | The native launcher can now launch Java and Bash binary in directory with non-English characters. Unfortunately, python doesn't support running python zip file under directory with non-English characters. eg. python ./??/bin.zip will still fail. See https://github.com/bazelbuild/bazel/issues/4473 Change-Id: I77fe9cdaabffc2e0d25c7097da5c0c9333a9c4a3 PiperOrigin-RevId: 201939391
* Windows,client: extract embedded binaries fasterGravatar Laszlo Csomor2018-06-25
| | | | | | | | | | | | | | | | | | | | When extracting embedded binaries, the client now caches which directories it has already created and won't attempt creating them again. This saves some time on Windows: from 16.3 sec on average down to 13.2 sec. (n=10 runs, always starting Bazel with a new --output_user_root and shutting down afterwards.) On Linux I see only a marginal speedup, not significant enough to claim credit for it. :) See https://github.com/bazelbuild/bazel/issues/5444 Closes #5448. PiperOrigin-RevId: 201933181
* Windows,Bazel client: check embedded tools fasterGravatar Laszlo Csomor2018-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | The Bazel client on Windows is now 50% faster to check the embedded tools than it was before. Results: - Linux: 20 ms -> 6 ms - Windows: 294 ms -> 133 ms Measurements were done with n=10 runs and a hot server, using blaze::GetMillisecondsMonotonic(). Previously the client performed the same tasks multiple times while trying to determine if a path was a good extracted binary. (E.g. converted the path to Windows format multiple times, checked if it was a directory twice, opened the path twice.) Now the client performes these tasks only once, e.g. it converts path once and stats only once. See https://github.com/bazelbuild/bazel/issues/5444 Closes #5445. PiperOrigin-RevId: 201913758
* Make the system bazelrc configurable.Gravatar ccalvarin2018-06-20
| | | | | | | | | | | The master bazelrc is now defined by preprocessor macro at (Bazel's) compile time. The default is still /etc/bazel.bazelrc for most platforms, but windows now has a %ProgramData% relative default value as well. Users wishing to change this default when building Bazel for a new platform should edit BAZEL_SYSTEM_BAZELRC_PATH in src/main/cpp/BUILD. Part of https://github.com/bazelbuild/bazel/issues/4502, relevant to the duplicate issue #4809. TESTED: default settings were tested manually, since they cannot be tested in a sandbox RELNOTES: Windows default system bazelrc is read from the user's ProgramData if present. PiperOrigin-RevId: 201423446
* PiperOrigin-RevId: 201390253Gravatar Googler2018-06-20
|
* Make blaze_util::AsAbsoluteWindowsPath support wstring as inputGravatar Yun Peng2018-06-20
| | | | | | | | | | | | | | Now we have: bool AsAbsoluteWindowsPath(const std::wstring& path, std::wstring* result, std::string* error); This change helps making the C++ native launcher work with UTF-16. See https://github.com/bazelbuild/bazel/issues/4473 Closes #5406. Change-Id: I7eaf55f9fe5a4d41e3dd09edc2a21e9b3cc9277c PiperOrigin-RevId: 201352866
* [Windows] Fix kOneYear initializationGravatar Loo Rong Jie2018-06-20
| | | | | | | | | | | | | | | Fix breakage introduced in #5385 due to incorrect use of `std::move` on local temporary variable after function returns (found by Clang on Windows). Since `OneYearDelay` function will return the same value and `kOneYear` is only used in one place, remove unused `OneYearDelay` function and move `kOneYear` to `GetFuture` as a `constexpr` constant. Drive-by improvement: remove some const reference in function signatures. `FILETIME` is a plain C struct with size of 64-bit, so it is trivially-copyable and can easily fit into a 64-bit register. It is more efficient to pass `FILETIME` by value (smaller code size). /cc @laszlocsomor Closes #5434. Change-Id: I136fe4a8ce1b274a80e3206b62e6087dd0f8f5eb PiperOrigin-RevId: 201343053
* Add a utility function to accept windows-style envvars in paths.Gravatar ccalvarin2018-06-19
| | | | | | | | | | | For paths passed to Bazel on the command line, the shell expands these variables, but for hardcoded defaults, we must make the library call ourselves. We do not add similar support in Posix systems, where it is less common to rely on standard path-related variables. Prerequisit for issue #4502. RELNOTES: None. PiperOrigin-RevId: 201183214
* do not start server if shutdown requested (+ not in batch mode)Gravatar Googler2018-06-19
| | | | PiperOrigin-RevId: 201144030
* Remove the connect-to-server dots at server startup.Gravatar ccalvarin2018-06-15
| | | | | | | | Replace with an update at most every 10 seconds if we are still trying to connect. TESTED: Tested manually that this does print every 10 minutes if the server is prevented from connecting. RELNOTES: None. PiperOrigin-RevId: 200764279
* Windows: fix "corrupt installation" at new yearGravatar Laszlo Csomor2018-06-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Bazel on Windows is now consistent with Bazel on Unixes, by setting the mtimes of embedded binaries to 10 years in the future. Before this change, on Windows, Bazel used to set these mtimes to CURRENT_YEAR + 10, January 1st. This meant that if a user ran Bazel on 2017/12/29, then on Unix Bazel set the mtimes to 2027/12/29 but on Windows it set them to 2027/01/01. If the user then ran Bazel in the same workspace on 2018/01/02, on Unixes it worked fine, but on Windows it detected that the embedded binaries' mtime is older than 2018/01/01, and reported a "corrupt installation" error. Fixes https://github.com/bazelbuild/bazel/issues/4378 Change-Id: I3457bdc360a62a279d1d08c9a69997929f2067dd Closes #5385. Change-Id: I3457bdc360a62a279d1d08c9a69997929f2067dd PiperOrigin-RevId: 200395493
* update bazel's embedded jdk to jdk9Gravatar cushon2018-06-11
| | | | | | | | | | | - Updates the embedded JDK to Azul Zulu 9.0.7 - All integration tests use Bazel with the embedded JDK Also updated: http://storage.googleapis.com/bazel-mirror/openjdk/index.html Closes #5312, #5314, #5315 PiperOrigin-RevId: 200055008
* Remove usage of COMPILER_MSVC in Bazel and ijarGravatar Loo Rong Jie2018-06-11
| | | | | | | | | | | | | Convert most `COMPILER_MSVC` to `_WIN32` (as they apply to Windows platform, not MSVC compiler). Only `src/tools/singlejar/zip_headers.h` and `src/main/cpp/util/md5.h` actually need `_MSC_VER`. `COMPILER_MSVC` in `third_party/protobuf` are not removed. They can be fixed by updating dependency to newer version. /cc @meteorcloudy Closes #5350. Change-Id: Ibc131abfaf34a0cb2bd338549983ea9d28eaabfe PiperOrigin-RevId: 200019793
* blaze_util::ConvertPath should not make paths absolute.Gravatar ccalvarin2018-06-07
| | | | | | | | | It does not claim to, and this was already true for posix platforms. Windows platforms, however, always made the path absolute, which was a hard-to-diagnose difference between the two. Similarly, MakeAbsolute was relying on this to be correct for windows, so this change splits the implementation and keeps the behavior consistent. While we're here, also remove the empty-string behavior from MakeAbsolute, and instead make it clear at all sites that this behavior is present and affects accepted flag syntax. We may want to remove this later. RELNOTES: None. PiperOrigin-RevId: 199663395
* Move path-manipulation functions to own library file.Gravatar ccalvarin2018-06-05
| | | | | | | | | | | Leave functions that make file accesses in the file library, and general blaze utilities in the blaze_util file, but move the functions that boil down to string manipulation and path formatting to their own file. (With the exception of getCWD, since absolute path syntax is relevant here.) Doing this largely to consolidate all Windows path control into a single place, so that it's easier to notice inconsistencies. For instance, ConvertPath currently makes Windows paths absolute, but not Posix paths, and MakeAbsolute relies on this behavior. In addition, JoinPath assumes Posix path syntax, which leads to some odd looking paths. These will be fixed in a followup change. (Found these issues while working on #4502, trying to fix the windows-specific system bazelrc.) RELNOTES: None. PiperOrigin-RevId: 199368226
* Set no_proxy=localhost when an http_proxy is detected, instead of deleting ↵Gravatar ruperts2018-06-04
| | | | | | | | | the http_proxy value. Also change the environment for the client and the server in this case, instead of only changing the server's environment. RELNOTES: None. PiperOrigin-RevId: 199152406
* Add --ignore_all_rc_files startup options.Gravatar ccalvarin2018-05-15
| | | | | | | | | | | | | This overrides --bazelrc and --[no]master_bazelrc regardless of order. Like --bazelrc and --[no]master_bazelrc, it cannot be mentioned in an rc file, this would be a contradiction. This flag is useful for testing, and for having a version-agnostic way to turn off all rc files, such as in the canonical command line reporting. Now that blazerc and bazelrc are separate, this is necessary. If explicit values for --bazelrc or --master_bazelrc are provided which are now ignored, Bazel will warn the user. #4502 Alternatives considered - We could avoid this flag but would need to have some well-documented, reusable list of the startup flags that effectively come to the same effect. This would be necessary in our integration tests and in the CommandLineEvent and other places where rc files need to be completely disabled for correctness. We decided that this startup option was more straightforward and usable for both users and Bazel devs: it shouldn't be used when more fine-grained control is needed, but provides warnings if users are likely to be confused by the outcome. RELNOTES: None. PiperOrigin-RevId: 196750704
* Windows, Java launcher: Support jar files under different drivesGravatar Yun Peng2018-05-14
| | | | | | | | | Create junctions to jar's directory when java launcher and its jar are under different drives Fixed https://github.com/bazelbuild/bazel/issues/5135 Change-Id: I21c5b28f5f36c1fe234f8b781fe40d526db846cc PiperOrigin-RevId: 196477704
* Use the local JDK as the default target javabaseGravatar cushon2018-05-14
| | | | | | and continue to use the embedded JDK as the default host_javabase. PiperOrigin-RevId: 196471714
* c++,runfiles: move runfiles libraryGravatar Laszlo Csomor2018-04-30
| | | | | | | | | | | | | | | | Move the half-done C++ runfiles library to `//tools/cpp/runfiles`. (The Python and Bash runfiles libraries are already under `//tools/<language>/runfiles`.) See https://github.com/bazelbuild/bazel/issues/4460 Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7 Closes #5107. Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7 PiperOrigin-RevId: 194763392
* Automated rollback of commit 52356e76a02067e9dc79b469e9b97bd017d077ab.Gravatar jingwen2018-04-27
| | | | | | | | | | | *** Reason for rollback *** Breaks Bazel CI pipeline (pre and postsubmits) on all platforms: https://buildkite.com/bazel/bazel-bazel/builds/1785 Fixes https://github.com/bazelbuild/bazel/issues/5113 RELNOTES: None. PiperOrigin-RevId: 194620643
* Automatic code cleanup.Gravatar Googler2018-04-27
| | | | PiperOrigin-RevId: 194602500
* windows,client: no longer support Unix-style pathsGravatar Laszlo Csomor2018-04-26
| | | | | | | | | | | | | | The Bazel client no longer supports MSYS paths. The only exception is "/dev/null" which the client treats as "NUL". After this change you can no longer pass MSYS paths as Bazel flag values on Windows. See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: I39d81843015c5a4014dd5953bac2e1c29dcd5bed PiperOrigin-RevId: 194372504
* windows,client: fix error reportingGravatar Laszlo Csomor2018-04-24
| | | | | | | | | | | | | | | | | | | | | | Fix error reporting in the path conversion methods of the Bazel client. Previously the error reporting logic used GetLastErrorString in places where it was not appropriate (i.e. it was not a failed Windows API call that caused an error). This cleanup prepares removing the concept of the MSYS root from the Bazel client, since MSYS paths are no longer supported and we want to cut Bazel's dependency on Bash (thus MSYS) completely. See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088 Closes #5072. Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088 PiperOrigin-RevId: 194052665
* Declare internal helper functions in option_processor-internal.Gravatar ccalvarin2018-04-23
| | | | | | | It's better for testing, while keeping it clear that these functions should not be used outside of option_processor.cc. RELNOTES: None. PiperOrigin-RevId: 193947022
* Remove overlap between the blazerc and bazelrc names.Gravatar ccalvarin2018-04-20
| | | | | | | | Bazel now has its own subclass of StartupOptions to specify bazel-only options. This is needed for https://github.com/bazelbuild/bazel/issues/4502. RELNOTES(INC): No longer accepts --blazerc or --[no]master_blazerc, accepts bazelrc name only. PiperOrigin-RevId: 193718297
* Reduce the state kept in OptionProcessor.Gravatar jmmv2018-04-19
| | | | | | | | | | | | | | | Make the list of rc files a local variable as it need not be a class attribute, and drop the unused rcoptions_ field. This is a trivial refactoring and the remaining code is still too confusing. It'd be worth splitting OptionProcessor in two pieces: OptionProcessor to exclusively keep the virtual ParseOptions method and no state, and a new ParsedOptions type to act as the immutable return value of ParseOptions. This would decouple all state mutations. RELNOTES: None. PiperOrigin-RevId: 193557347
* Refactor where rc files are controlled.Gravatar ccalvarin2018-04-19
| | | | | | | In preparation for https://github.com/bazelbuild/bazel/issues/4502, make OptionProcessor::GetRcFiles contain the logic for both the user bazelrcs and the master bazelrcs. RELNOTES: None PiperOrigin-RevId: 193521683
* windows: change output_base name computationGravatar Laszlo Csomor2018-04-19
| | | | | | | | | | | | | | | | | Change GetHashedBaseDir in the Bazel client on Windows, to only use an alphabet of 32 characters, not of 64. The 64-element alphabet contained effective repetitions because path names on Windows are case-insensitive. Fixes https://github.com/bazelbuild/bazel/issues/5053 Change-Id: I2cfb40e32684ff42b95334e08e4d56ee318a57ca Closes #5054. Change-Id: I4225fd8a92634ff26ae2154af9298bda33bea6ac PiperOrigin-RevId: 193507800
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-01 15:20:01 +0000