aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/cpp/startup_options.cc
Commit message (Collapse)AuthorAge
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* Bring startup_options to BAZEL_LOG.Gravatar ccalvarin2018-04-10
| | | | | RELNOTES: None. PiperOrigin-RevId: 192313667
* Remove the --allow_configurable_attributes startup option.Gravatar ccalvarin2018-03-27
| | | | | | | It was removed from the java code 4 years ago, mentioning it causes the server to crash at startup. RELNOTES: None. PiperOrigin-RevId: 190636455
* Flip --expand_configs_in_place to true by default in Bazel.Gravatar ccalvarin2018-02-23
| | | | | | | See https://blog.bazel.build/2018/01/19/config-parsing-order.html for context on this change. RELNOTES: --config flags now expand in place by default. PiperOrigin-RevId: 186831701
* Support explicitly specifying a location for jvm.outGravatar michajlo2018-01-29
| | | | | | | | Allows users to monitor server output without needing to fish the output base. Windows support is copied more or less verbatim from recommendations, I unfortunately don't know how to test this on windows. PiperOrigin-RevId: 183674130
* Add hooks to Bazel client for adding memory and logging specific JVM flags.Gravatar ajmichael2017-12-13
| | | | | | This refactoring is not currently used in Bazel, but is necessary for our internal variant. RELNOTES: None PiperOrigin-RevId: 178947759
* Change config expansion application order, gated by startup flag ↵Gravatar ccalvarin2017-11-20
| | | | | | | | | | | | | --expand_configs_in_place. --config options were expanded in a fix-point expansion, where in practice, the flags that --config values expanded to ended up between the normal bazelrc options and the command line's explicit options. Since the options parser has an order-based priority scheme and it accepts multiple mentions of a single-valued option, this conflicts with users' expectations of being able to override these config expansions by using the order in which they are mentioned. This change makes it possible to expand the config values defined in your bazelrc (or blazerc) files to occur in-place: --stuff --config=something --laterstuff will interpret the options that --config=something expands to as if they had been mentioned explicitly between --stuff and --laterstuff. In order to not break users relying on complex flag combinations to configure their builds, this behavior will not yet be turned on by default. Instead, use --expand_configs_in_place as a startup flag to test this feature. --announce_rc may be helpful for debugging any differences between the fixed point and in-place expansions. Once you've debugged your problems, add "startup --expand_configs_in_place" to your blazerc to stick to the new behavior. RELNOTES: Use --expand_configs_in_place as a startup argument to change the order in which --config expansions are interpreted. PiperOrigin-RevId: 176371289
* Update java check in StartupOptions::GetJvm() to work with java9Gravatar Chris Heisterkamp2017-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you have java 9 installed but JAVA_HOME is set to java 8 then some bazel tests will fail because the check for java cannot find rt.jar which no longer exists in java 9. e.g. on OSX 10.13 ``` > java -version java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) > JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home bazel test //src/test/py/bazel:action_temp_test ``` will fail with the following ``` FAIL: testLinuxOrDarwinSandboxedBuildAction (__main__.ActionTempTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/bazel-out/local-fastbuild/bin/src/test/py/bazel/action_temp_test.runfiles/io_bazel/src/test/py/bazel/action_temp_test.py", line 30, in testLinuxOrDarwinSandboxedBuildAction self.AssertTempEnvvarWithSpawnStrategy('sandboxed') File "/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/bazel-out/local-fastbuild/bin/src/test/py/bazel/action_temp_test.runfiles/io_bazel/src/test/py/bazel/action_temp_test.py", line 39, in AssertTempEnvvarWithSpawnStrategy strategies = self._SpawnStrategies() File "/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/bazel-out/local-fastbuild/bin/src/test/py/bazel/action_temp_test.runfiles/io_bazel/src/test/py/bazel/action_temp_test.py", line 124, in _SpawnStrategies self.AssertExitCode(exit_code, 2, stderr) File "/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/bazel-out/local-fastbuild/bin/src/test/py/bazel/action_temp_test.runfiles/io_bazel/src/test/py/bazel/test_base.py", line 68, in AssertExitCode '(end stderr)------------------------------------------', AssertionError: Bazel exited with 1 (expected 2), stderr: (start stderr)---------------------------------------- INFO: $TEST_TMPDIR defined: output root default is '/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/_tmp/30efe0ec7addffc49fb72b5d5aa45572' and max_idle_secs default is '15'. Extracting Bazel installation... Problem with java installation: couldn't find/access rt.jar in /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home (end stderr)------------------------------------------ ``` This is related to https://github.com/bazelbuild/bazel/issues/428 but really only fixes the case where you are still using java8 but happen to have java9 installed. Closes #4045. PiperOrigin-RevId: 175513188
* Some minor quality of life improvements related to the fact that the default ↵Gravatar nharmata2017-11-07
| | | | | | | | | | value of --max_idle_secs is 15s when the TEST_TMPDIR environment variable is set. (i) Add a log line to blaze.INFO when the server shuts itself down due to idleness. (ii) Mention the --max_idle_secs default in the existing stderr spam when TEST_TMPDIR is set. RELNOTES: None PiperOrigin-RevId: 174745511
* Increase the connection timeout between the client and the server.Gravatar lberki2017-09-25
| | | | | | | Very large server instances can take >10 seconds for GC, and if they are hit at an inopportune moment, they may get killed needlessly. RELNOTES: None. PiperOrigin-RevId: 169905185
* Send Bazel startup options to server.Gravatar ccalvarin2017-08-16
| | | | | | | | | | | Send the startup options tagged with their origin so that the server has correct information about the command line as the client received it. Removes the unconditional stderr printing of all bazelrc startup options in the bazel client. Instead, the startup options are sent to the server and the same informational printing is gated on the --announce_rc option. This avoids unconditional log spam to stderr early in startup. If the server is unreachable or there are errors parsing startup options, the message is still printed to stderr. Fixes https://github.com/bazelbuild/bazel/issues/2530. RELNOTES: --announce_rc now controls whether bazelrc startup options are printed to stderr. PiperOrigin-RevId: 165211007
* 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
* 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-26
| | | | | RELNOTES: None. PiperOrigin-RevId: 160111047
* 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
* 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
* Remove configurability of abrupt exit code behavior.Gravatar ccalvarin2017-03-29
| | | | | | | | Ability to configure this was added to provide an easy correction in case writing the exit code to a file proved problematic. This feature has been out for 3 months with no reported issues, no reason to keep the extraneous flag. PiperOrigin-RevId: 151496431
* Build a version of Bazel with a bundled OpenJDK inside the binary.Gravatar Philipp Wollermann2017-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're using Azul Systems, Inc.'s Zulu® OpenJDK build[1], as it's a good vanilla build of OpenJDK available for our three most important platforms: zulu8.20.0.5-jdk8.0.121-linux_x64.tar.gz zulu8.20.0.5-jdk8.0.121-macosx_x64.zip zulu8.20.0.5-jdk8.0.121-win_x64.zip You can build & run a Bazel binary with an embedded JDK by simple doing: bazel build //src:bazel_with_jdk bazel-bin/src/bazel_with_jdk info The "bazel license" command prints the license of the embedded OpenJDK. We mirror the binaries and sources of the OpenJDK used for bundling on this website: https://bazel-mirror.storage.googleapis.com/openjdk/index.html RELNOTES: Bazel can now be built with a bundled version of the OpenJDK. This makes it possible to use Bazel on systems without a JDK, or where the installed JDK is too old. [1] http://www.azul.com/downloads/zulu/ -- PiperOrigin-RevId: 150440467 MOS_MIGRATED_REVID=150440467
* Increase log size limit to 10M.Gravatar Julio Merino2017-03-10
| | | | | | | | | | The log size is specified in number of bytes, not number of records, and the previous 50k limit was too small to hold any significant amount of data. 10M should be good to hold enough to troubleshoot issues. -- PiperOrigin-RevId: 149660970 MOS_MIGRATED_REVID=149660970
* Bazel client: use PathAsJvmFlag for JVM flagsGravatar Laszlo Csomor2017-03-09
| | | | | | | | | | | | | | | | | The Windows-implementation of this function shortens paths that we pass to the JVM, such as the Bazel server jar's path, the log file path, etc. These must be shortened because the JVM doesn't handle long paths. We don't shorten paths passed to the Bazel server itself though because Bazel can handle long paths. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 149548361 MOS_MIGRATED_REVID=149548361
* Convey the value of the --host_javabase startup option to the server.Gravatar Lukacs Berki2017-03-06
| | | | | | -- PiperOrigin-RevId: 149282686 MOS_MIGRATED_REVID=149282686
* 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
* Convert --use_action_cache to a regular optionGravatar Googler2017-03-01
| | | | | | | | RELNOTES: Convert --use_action_cache to a regular option -- PiperOrigin-RevId: 148804881 MOS_MIGRATED_REVID=148804881
* Bazel client: make jvm.log path platform-safe Gravatar László Csomor2017-02-24
| | | | | | | | | | | | | | | | | When writing the javalog.properties file that configures the java logger, pass the log file path in a platform safe manner. Namely if we're running on Windows, don't write paths with backslashes because they are mistaken for paths with escaped characters. Fixes: https://github.com/bazelbuild/bazel/issues/2576 -- Change-Id: Ibd907c13f1ffe4561c3a4e737f0c2b25ec5d4b17 Reviewed-on: https://cr.bazel.build/9059 PiperOrigin-RevId: 148342757 MOS_MIGRATED_REVID=148342757
* Adds --[no]use_action_cache startup option to disable the action cache.Gravatar Googler2017-02-15
| | | | | | | | | Disabling the action cache is helpful in contexts where incremental builds are not required, or where actions need to be repeatedly executed for debugging. -- PiperOrigin-RevId: 147485055 MOS_MIGRATED_REVID=147485055
* 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
* Bazel client: platform-dependent `strerror` Gravatar László Csomor2017-01-27
| | | | | | | | | | | | | | Move `strerror` calls into errors_<platform>. We have to get rid of direct `errno` reading too, because it doesn't work on Windows native. Fixes https://github.com/bazelbuild/bazel/issues/2411 -- Change-Id: I69ff502487d698aa9e9147f02fd0bc5253e94e64 Reviewed-on: https://cr.bazel.build/8490 PiperOrigin-RevId: 145777524 MOS_MIGRATED_REVID=145777524
* 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
* Bazel client: generalize path handlingGravatar Laszlo Csomor2016-12-19
| | | | | | | | | | | | | | Use/implement utility methods to join paths, check if they are the root directory or are absolute, etc. Doing so (instead of say checking if a path starts with "/") allows for correct behavior on Windows. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 142446027 MOS_MIGRATED_REVID=142446027
* Record correct exit code for uncaught exceptions in async threads.Gravatar Chloe Calvarin2016-12-13
| | | | | | | | | | Async threads are divorced from the server's error-reporting mechanism. In the event of a server shutdown originating in an async-thread, write the exit code to a file that can be read by the client. -- PiperOrigin-RevId: 141920284 MOS_MIGRATED_REVID=141920284
* Description redacted.Gravatar Julio Merino2016-12-09
| | | | | | -- PiperOrigin-RevId: 141483567 MOS_MIGRATED_REVID=141483567
* Add SearchUnaryOptions and SearchNullaryOptions to improve the parsingGravatar Luis Fernando Pino Duque2016-12-09
| | | | | | | | | | | | of the startup options. This allows us to do the following: - Avoid using the product name when reporting startup option parsing errors. - Passing --bazelrc as a command argument throws an error (fix for issue #1659). -- PiperOrigin-RevId: 141445030 MOS_MIGRATED_REVID=141445030
* Remove the -x startup option.Gravatar Luis Fernando Pino Duque2016-12-08
| | | | | | | | | | | | This startup option was deprecated months ago, however it is currently parsed if present in the command line and a warning is shown. Now an error is thrown if it is passed in the command line. RELNOTES[INC]: The deprecated -x startup option has been removed. -- PiperOrigin-RevId: 141441381 MOS_MIGRATED_REVID=141441381
* Bazel client: platform-specific {Read,Write}FileGravatar Laszlo Csomor2016-11-28
| | | | | | | | | | | | | | | | Move blaze::ReadFile and blaze::WriteFile to file.h and file_platform.h (thus into the blaze_util namespace), and update references. This allows us to implement these methods in a platform-specific way. Also move UnlinkPath. See https://github.com/bazelbuild/bazel/issues/2107 -- MOS_MIGRATED_REVID=140328273
* Bazel client: reduce dependency on POSIX APIGravatar Laszlo Csomor2016-11-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can now compile blaze_util_windows.cc with MSVC, yay! (when building //src:bazel --cpu=x64_windows_msvc -k). There are a lot of #ifdef's and TODOs so this is a modest victory for now. In this change: - change blaze::MakeDirectories to return bool instead of int, since that's how it was used anyway, and to expect the permission mask as unsigned int instead of mode_t, since the former is good enough and compatible with mode_t on POSIX while mode_t is not defined on Windows - move blaze::MakeDirectories into blaze_util_<platform> - implement envvar-handling in blaze_util_<platform> and use it everywhere See https://github.com/bazelbuild/bazel/issues/2107 -- MOS_MIGRATED_REVID=139887503
* Provide a SplitCommandLine method in the option processorGravatar Luis Fernando Pino Duque2016-11-21
| | | | | | | | | | | | | that takes a given command line args and splits it into the corresponding {binary, startup_args, command, command_args}. The purpose of this function is to help split the responsibilities of the ParseOptions function by processing the startup options independently (i.e. rc files detection and processing) from the command options. This will be combined with ParseOptions in a subsequent CL. -- MOS_MIGRATED_REVID=139773786
* Bazel client: wrap some POSIX functionsGravatar Laszlo Csomor2016-11-10
| | | | | | | | | | | | | | This change: - starts using blaze_util::CanAccess and blaze_util::PathExists instead of access(2) - implements and starts using blaze_util::GetCwd instead of getcwd(2) - implements and starts using blaze_util::ChangeDirectory instead of chdir(2) - adds tests for the new wrapper methods -- MOS_MIGRATED_REVID=138750297
* Add two startup options:Gravatar Lukacs Berki2016-11-08
| | | | | | | | - --client_debug that turns out debug logging from the client - --connect_timeout_secs that controls the timeout of the initial Ping() RPC from the client to the server -- MOS_MIGRATED_REVID=138491791
* Description redacted.Gravatar Luis Fernando Pino Duque2016-11-02
| | | | | -- MOS_MIGRATED_REVID=137944374
* Add the IsNullary(arg) and IsUnary(arg, next_arg) functionsGravatar Luis Fernando Pino Duque2016-10-28
| | | | | | | to detect whether arg is a valid startup option. -- MOS_MIGRATED_REVID=137512954
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-29 08:08:46 +0000