aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/cpp/blaze.cc
Commit message (Collapse)AuthorAge
* Add a "direct" mode to "blaze run" that makes the process being run a directGravatar lberki2018-02-05
| | | | | | | | | | | | | | child of the process where the Blaze client itself was run. Limitations: - Untested on Windows; it should work because ExecuteProgram() is implemented there, too, but since Windows doesn't support exec(), there is at least one process in between Progress towards #2815. RELNOTES[NEW]: The new "--direct_run" flag on "blaze run" lets one run interactive binaries. PiperOrigin-RevId: 184528845
* Use the workspace name in the process title of the Bazel server.Gravatar philwo2018-02-01
| | | | | | | | This makes way more sense than using the name of the *parent* directory of the workspace. Closes #4253 - thanks @akira-baruah for suggesting this change and making it happen! PiperOrigin-RevId: 184147456
* Remove unnecessary debugging code.Gravatar philwo2018-01-31
| | | | PiperOrigin-RevId: 183995676
* Bazel client: address very subtle race condition during self extraction.Gravatar nharmata2018-01-30
| | | | | | | | | Fail fast if we are about extract the Bazel binary for version V into the predetermined install_base directory for version V'. This fixes Bazel's weakness to a race condition that puts it in a stable inconsistent state where all current and future attempts to use Bazel at version V will actually use V'. A rerun of the Bazel client will be able to successfully use version V'. This race condition occurs when the Bazel binary is replaced after determine the install directory (via the install_base_key file in the Bazel zip) but before we extract the files in the zip into the directory. RELNOTES: None PiperOrigin-RevId: 183843099
* 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
* Emit Blaze server pid when there is a connection timeout.Gravatar felly2017-11-30
| | | | | RELNOTES: None PiperOrigin-RevId: 177420511
* 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
* 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
* Make the error message emitted when the server crashes during startup a bit ↵Gravatar lberki2017-10-26
| | | | | | | more intelligible. RELNOTES: None. PiperOrigin-RevId: 173512953
* client: deduplicate classpath for Bazel serverGravatar Laszlo Csomor2017-10-23
| | | | | | | Fixes https://github.com/bazelbuild/bazel/issues/3938 Change-Id: Ic837f1b97cf8469434118f2660fb15d14c035a14 PiperOrigin-RevId: 173100466
* Automated rollback of commit 61977f4ae57c877fc28be176f36c28642b276eec.Gravatar lberki2017-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks a test of Bazel on Windows: http://ci.bazel.io/view/Dashboard/job/bazel-tests/1078/testReport/src_test_py_bazel_bazel_clean_test/exe/src_test_py_bazel_bazel_clean_test_exe/ Fixes #3882. *** Original change description *** Don't release the client lock while the server executes a command. The server still doesn't support concurrency, even for commands like 'help', so there's no benefit from releasing it. This also improves progress messages. Today the client may print WARNING: Running Blaze server needs to be killed, because the startup options are different. and then wait indefinitely while the server finishes processing a request. With this change, an explanation for the delay is given. RELNOTES: None. GO... *** RELNOTES: None. PiperOrigin-RevId: 171689429
* Don't release the client lock while the server executes a command. TheGravatar Googler2017-10-10
| | | | | | | | | | | | | | | server still doesn't support concurrency, even for commands like 'help', so there's no benefit from releasing it. This also improves progress messages. Today the client may print WARNING: Running Blaze server needs to be killed, because the startup options are different. and then wait indefinitely while the server finishes processing a request. With this change, an explanation for the delay is given. RELNOTES: None. PiperOrigin-RevId: 171571670
* Internal changeGravatar Googler2017-08-30
| | | | PiperOrigin-RevId: 166874758
* Bazel client: debug info for corrupt installationGravatar László Csomor2017-08-28
| | | | | | | | | | | | | | | | | | | | The Bazel client checks the installation files every time it starts. Bazel checks that it can read the installation files and that their mtimes are in the future. The "bazel-tests" project on Bazel CI recently produced flaky-looking failures. The error messages talk about a missing installation file. This change makes Bazel print more debugging info when the aformentioned check fails. I hope the information will help catching this bug. See https://github.com/bazelbuild/bazel/issues/3618 Change-Id: Ic51384b5840262484515fa320f162a79cfd0e012 PiperOrigin-RevId: 166696141
* Propagate detected value of BAZEL_SH to --client_env.Gravatar Dmitry Lomov2017-08-22
| | | | | | | | | | | | Also adds some extra debug logging. Also removes some msys-only code paths. Fixes #3498. This is a reland of commit 2f38404. Change-Id: I1690a64f427070cc3f127b857650e6a32d1aab35 PiperOrigin-RevId: 166049222
* Automated rollback of commit 2f38404728a12840e416566b453e9cdebab5d859.Gravatar elenairina2017-08-18
| | | | | | | | | | | | | | | | | | | | | Fixes #3584 *** Reason for rollback *** Broke bazel_windows_test fails on windows. *** Original change description *** Propagate detected value of BAZEL_SH to --client_env. Also make debug_log available as soon as possible on startup. Also adds some extra debug logging. Also removes some msys-only code paths. Fixes #3498. Change-Id: I5b769f2c5a728106e5252869745ec79e555cbaf2 PiperOrigin-RevId: 165692468
* Propagate detected value of BAZEL_SH to --client_env.Gravatar Dmitry Lomov2017-08-18
| | | | | | | | | | | Also make debug_log available as soon as possible on startup. Also adds some extra debug logging. Also removes some msys-only code paths. Fixes #3498. Change-Id: I5b769f2c5a728106e5252869745ec79e555cbaf2 PiperOrigin-RevId: 165574022
* 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
* Windows: detect if started from Windows ExplorerGravatar Laszlo Csomor2017-07-28
| | | | | | | | | | | | | Bazel now detects whether it was started from a command line (or as a subprocess), or from Windows Explorer (by clicking its icon). In the latter case it displays an error message asking the user to run it from a command line, and waiting for a keypress so the user has time to read this message. Change-Id: I4b0430e30d2f1f243cec6ff63cb3abac907e60e3 PiperOrigin-RevId: 163338527
* Include <cinttypes> instead of <stdint.h>Gravatar Damien Martin-Guillerez2017-07-27
| | | | | | | | | | | cinttypes is the C++ header that should replace stdint.h. Not using the correct header was leading to compilation error on CentOS 6.7 Fixes #3455. To be cherry-picked for #3375. Change-Id: I6df22134a4a4902ec9fa7ecdfaeb5408eacf3564 PiperOrigin-RevId: 163334651
* Implement bash.exe detection logic.Gravatar Dmitry Lomov2017-07-19
| | | | | | | | | | | | | | | | The logic is as follows: 1) search for msys installation 2) search got git-on-Windows installation 3) search in PATH. This happens on every client startup unless BAZEL_SH enviornment variable is set. My measurements show that the time required for this detection is negligible (<10 msec in the worst case). Change-Id: If130e2491a9df5a23954d303f2ccdb932eeed1db PiperOrigin-RevId: 162466913
* Ensure that shutdown commands end the server process before completionGravatar mschaller2017-07-12
| | | | | | | | | | | | | | | | | | | | This change ensures that the server process is terminated before the client process terminates, when evaluating a command that shuts down the server. When completing such a command, the server communicates to the client that the server will terminate itself by setting a termination_expected bit in the final RunResponse message. The client then waits up to 60s for the server process to actually terminate. If it does not, then the client SIGKILLs the server. Also makes the gRPC server stop accepting new commands before the shutdown command completes. Drive-by fix to comments on Search{Un,Null}aryOption. RELNOTES: Commands that shut down the server (like "shutdown") now ensure that the server process has terminated before the client process terminates. PiperOrigin-RevId: 161537480
* Delete the unused OptionProcessor::ParseOptions(argc,argv).Gravatar lpino2017-07-11
| | | | PiperOrigin-RevId: 161523047
* 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
* Don't set the +x bit by default on WriteFile().Gravatar lberki2017-06-27
| | | | | | | This change is a spiritual successor of https://bazel-review.googlesource.com/c/7410/ . That one had a merge conflict and it was small enough that a rewrite was easier than updating it. RELNOTES: None. PiperOrigin-RevId: 160251282
* Bazel client: explain the name of A-server.jarGravatar László Csomor2017-06-07
| | | | | | | | | | Also add a helper method to GlobalVariables to retrieve this path, thus concentrating the assumptions about the layout of extracted_binaries in one place. Change-Id: If172b6f5bf4451845ad89d3d488ef2a2c2e5d286 PiperOrigin-RevId: 158241854
* Fix a bunch of issues related to server startup/shutdown:Gravatar lberki2017-06-06
| | | | | | | | | - Only try to communicate with the server if it passes verification (i.e. the indicated PID exists and its start time is correct) - Use only one thread to delete files on exit - Don't set restart reason to NEW_VERSION unless there is an existing server RELNOTES: None. PiperOrigin-RevId: 158131470
* Add new reasons for server restart: PID_FILE_BUT_NO_SERVER, SERVER_VANISHED ↵Gravatar janakr2017-05-17
| | | | | | and SERVER_UNRESPONSIVE, since it looks like these are happening with upsetting frequency in our new grpc world. PiperOrigin-RevId: 156271743
* cpp: remove out-dated StartServer() documentation commentGravatar Thiago Farina2017-05-15
| | | | | | | | Since commit 1977d92e17e6: ("Various cleanups and refactorings in the client:"), StartServer() does not return a file descriptor anymore. Change-Id: I920240d3aed5f16077bf9f046522b65664319947 PiperOrigin-RevId: 155871851
* cpp: remove all code supporting kServerPidSymlinkGravatar Thiago Farina2017-05-09
| | | | | | | | By this time (6 months later) Bazel clients should no longer need this. Change-Id: Ib058065a0ff3eedc777e95c7d06602ca6744d42a PiperOrigin-RevId: 155478543
* cpp: add PrintWarning() function to errors.hGravatar Thiago Farina2017-05-09
| | | | | | | | | It provides a single and clean way to output warning messages, and replaces the fprintf(stderr, "Warning: ...\n") or fprintf(stderr, "WARNING: ...\n") calls. Change-Id: I2f8a8f659085b9e57a08b5208a8b8f683a7cd72c PiperOrigin-RevId: 155386233
* cpp: turn ListSeparator() function into a constantGravatar Thiago Farina2017-04-25
| | | | | | | | It does not need to be a fully allocated std::string every time. A simple character constant is enough for it. Change-Id: I98b9d4bb77932ea18646fbc793132e089bc66124 PiperOrigin-RevId: 154054987
* cpp: remove unncessary function prototypesGravatar Thiago Farina2017-04-24
| | | | | | | | It is not necessary to have these function declarations (prototypes) because they are declared+defined before they are actually called. Change-Id: I32d9ba82e056e368eecc553569231ad1174ad5e0 PiperOrigin-RevId: 154035760
* Avoid false positive uninitialized variable use warning in blaze.ccGravatar Peter Foley2017-04-11
| | | | | | | fprintf(stderr, "\nCannot write to %s; exiting...\n\n", broken_pipe_name); Closes #2736. PiperOrigin-RevId: 152675241
* Move InvocationPolicy from a startup argument to part of the RunRequest proto.Gravatar ccalvarin2017-04-07
| | | | | | | | | The user interface is not changing. The policy will still be accepted as a flag passed to the client, as a startup flag (before the command), it will just no longer trigger server restarts and will not be passed on to a bazel server as part of the startup arguments. In batch mode, however, it will still be a startup argument, because the RunRequest proto is not sent, and all invocations restart bazel in batch mode anyway. Since invocation policy only affects command arguments, and changes in command arguments do not cause server restarts, this is consistent with other server restart behavior. RELNOTES: Changing --invocation_policy will no longer force a server restart. PiperOrigin-RevId: 152426207
* Bazel client: simplify ReadDirectorySymlinkGravatar laszlocsomor2017-03-31
| | | | | | | | | | | | | | | This is a bugfixed version of https://cr.bazel.build/9520 which broke some Google-internal tests. This change allows removing duplicate code: ReadDirectorySymlink was implemented on Windows as a junction resolver, which is also implemented in file_windows.cc. Now it uses the JunctionResolver. RELNOTES: none PiperOrigin-RevId: 151691895
* 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
* 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: 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
* 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
* 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
* gRPC improvements:Gravatar Lukacs Berki2017-02-13
| | | | | | | | | | | - Differentiate between the server terminating abruptly and it erroneously not returning an exit code. - Do not assume that the message buffer stays untouched on the last call to Read() that eventually returns false. There is a small chance that the channel will be shut down because it's idle between Read() returning false and us checking the state. Unfortunately, I haven't found a way to set the idle timeout from C++ :( -- PiperOrigin-RevId: 147321404 MOS_MIGRATED_REVID=147321404
* 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
* 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: 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
* Add a comment to clarify why we set the mtime on the install base.Gravatar Lukacs Berki2017-01-17
| | | | | | -- PiperOrigin-RevId: 144688363 MOS_MIGRATED_REVID=144688363
* When the server doesn't return an exit code, add the location of the server ↵Gravatar Lukacs Berki2017-01-13
| | | | | | | | | | log file to the error message. Helps with #2309. Hopefully. -- PiperOrigin-RevId: 144431711 MOS_MIGRATED_REVID=144431711
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 05:46:40 +0000