aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/cpp
Commit message (Collapse)AuthorAge
* Expose --output_user_base to the Bazel server processGravatar Klaus Aehlig2018-02-27
| | | | | | | | | | | ...so that it can use that path to compute other directories in the output user base, in particular the default location for caches. The first cache we will add is the hash-index cache for downloads of external archives, but a spawn cache might be added later in the output user base as well. Change-Id: I24b1c33235c8f76ec008ecb1789163de2b2a45be PiperOrigin-RevId: 187164275
* Use std::to_string for non-mingw/cygwinGravatar Loo Rong Jie2018-02-27
| | | | | | | | | | `std::to_string` is faster than `std::stringstream`. This issue only presents in older versions of Mingw/Cygwin. My Mingw64 GCC 7.1.0 has `std::to_string`. I can't determine the exact version of GCC that fixed the issue. Closes #4493. PiperOrigin-RevId: 187145391
* 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
* windows: replace custom JunctionResolverGravatar Laszlo Csomor2018-02-22
| | | | | | | | | | | | There's a realpath(3)-like Windows API function called GetFinalPathNameByHandle{A,W}. This commit removes JunctionResolver, implements RealPath using GetFinalPathNameByHandleW, and replaces JunctionResolver usages with RealPath. Change-Id: I69efd29c139e957a93496cd75a2db351ed4453e1 PiperOrigin-RevId: 186598195
* Bazel client: remove dead codeGravatar Laszlo Csomor2018-02-20
| | | | | | | | | Remove the static kAsciiPropertyBits data from strings.cc and replace its only reference with simpler code. Change-Id: I95fb12b7d4bca4589ae64603b63019ee6e12bfc2 PiperOrigin-RevId: 186295165
* [MSVC] Detect 64-bit with _WIN64Gravatar Loo Rong Jie2018-02-14
| | | | | | | Fixes MSVC C4311 pointer truncation warning. Change-Id: Ic64168d620db010717189200c37c419cccac0653 PiperOrigin-RevId: 185653953
* [Windows] Use %ls to print wstringGravatar Loo Rong Jie2018-02-13
| | | | | Change-Id: Icbc478f87d622665b16c13c76518087ac089899e PiperOrigin-RevId: 185645880
* Automatic ClangTidyReadability code cleanup.Gravatar Googler2018-02-13
| | | | PiperOrigin-RevId: 185528799
* [MSVC] Don't declare environ when it is already defined as macroGravatar Loo Rong Jie2018-02-12
| | | | | | | | | | | | | | | | In MSVC, `environ` is a macro (from `stdlib.h`): ```cpp extern char*** __p__environ(void); #define _environ (*__p__environ()) #define environ _environ ``` So `extern char **environ;` will be expanded as `extern char **(*__p_environ());` which is invalid. This causes compile warning on MSVC. Closes #4487. PiperOrigin-RevId: 185354631
* Combine WorkspaceRcFileSearchPath and FindCandidateBlazercPaths and add a test.Gravatar ajmichael2018-02-07
| | | | | RELNOTES: None PiperOrigin-RevId: 184865343
* Refactor blazerc parsing out of OptionProcessor. This change should be a ↵Gravatar Googler2018-02-07
| | | | | | | no-op behavior-wise. RELNOTES: None PiperOrigin-RevId: 184843442
* 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
* Remove dead ConvertPathListGravatar Loo Rong Jie2018-01-26
| | | | | | Closes #4494. PiperOrigin-RevId: 183380779
* Support negated flags in SearchNullaryOption with last-wins semantics.Gravatar ajmichael2018-01-24
| | | | | | | `blaze --nomaster_bazelrc --master_bazelrc` now uses the master bazelrc. RELNOTES: None PiperOrigin-RevId: 183083839
* Clean up Windows config_settingsGravatar Yun Peng2018-01-12
| | | | | | | | | | | | | | 1.Deleted config_setting for --cpu=x64_windows_msys, because we don't build Bazel with MSYS gcc anymore. 2.Deleted config_setting for --cpu=x64_windows_msvc, because it uses exactly the same toolchain as --cpu=x64_windows, it'll be removed in the future. This change reduces the complexity of our BUILD files and make them less confusing. Change-Id: I939831a6861413b0f745fb1be98aacd4fb780e0a PiperOrigin-RevId: 181751853
* Windows, Java launcher: Use relativize paths in classpath jarGravatar Yun Peng2018-01-11
| | | | | | | Fixed https://github.com/bazelbuild/bazel/issues/4408 Change-Id: Id62b25e675822bbed91a448e70bdcb76e722721e PiperOrigin-RevId: 181591585
* Initialize server_pid in an attempt to convince a linter that ↵Gravatar lberki2018-01-09
| | | | | | | | | ExecuteDaemon() always returns a defined value. Fixes #4394. RELNOTES: None. PiperOrigin-RevId: 181315375
* 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
* Update out-of-date comment in option_processor.Gravatar ccalvarin2017-12-11
| | | | | RELNOTES: None PiperOrigin-RevId: 178641317
* Getting rid of compiler warning "control reaches end of non-void function ↵Gravatar olaola2017-12-06
| | | | | | [-Wreturn-type]". PiperOrigin-RevId: 178115185
* Add return statements to silence compiler warning.Gravatar John Cater2017-12-06
| | | | | Change-Id: Ic39712b613a0400f595a7db6e6f957057775b1b8 PiperOrigin-RevId: 178101141
* Windows: Don't leak any handles from Bazel client to Bazel serverGravatar Yun Peng2017-12-01
| | | | | | | | | | | Explicitly specify which handles to inherit Fixes https://github.com/bazelbuild/bazel/issues/4193 Fixes https://github.com/bazelbuild/bazel/issues/2182 Fixes https://github.com/bazelbuild/bazel/issues/2248 Change-Id: Ifa0201a6764c633016784c245d480542966efc6d PiperOrigin-RevId: 177564007
* Move bazel conditions into src/conditions.Gravatar tomlu2017-11-30
| | | | | | | This will enable an easier transition from checked-in BUILD files to ones generated by copybara. RELNOTES: None PiperOrigin-RevId: 177514519
* Emit Blaze server pid when there is a connection timeout.Gravatar felly2017-11-30
| | | | | RELNOTES: None PiperOrigin-RevId: 177420511
* Print 'waiting for other blaze command' on its own line.Gravatar Googler2017-11-28
| | | | | | | | | | It now prints a newline char immediately, rather than waiting until the lock is released, and printing 'done!' at the end of the line. This allows per-line parsers (like IntelliJ) to display this progress notification without special-case hacks. PiperOrigin-RevId: 177180918
* 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
* Make the error message emitted when the server crashes during startup a bit ↵Gravatar lberki2017-10-26
| | | | | | | more intelligible. RELNOTES: None. PiperOrigin-RevId: 173512953
* Windows, jni: Don't close stdout/stderr in nativeWaitFor functionGravatar Yun Peng2017-10-24
| | | | | | | | | | | | | | | | | | | | | | | | These two close operations were added to work around #1708, but caused #2675. We found the root cause of the hanging problem in #1708 is a race condition when creating Windows processes: When Bazel trys to create two processes, one for a local command execution, one for starting the worker process. The worker process might accidentally inherits handles opened when creating the local command process, and it holds those handles as long as it lives. Therefore, ReadFile function hangs when handles for the write end of stdout/stderr pipes are released by the worker. The solution is to make Bazel native createProcess JNI function explicitly inheirts handles as needed, and use this function to start worker process. Related: http://support.microsoft.com/kb/315939 Fixed https://github.com/bazelbuild/bazel/issues/2675 Change-Id: I1c9b1ac3c9383ed2fd28ea92f528f19649693275 PiperOrigin-RevId: 173244832
* client: deduplicate classpath for Bazel serverGravatar Laszlo Csomor2017-10-23
| | | | | | | Fixes https://github.com/bazelbuild/bazel/issues/3938 Change-Id: Ic837f1b97cf8469434118f2660fb15d14c035a14 PiperOrigin-RevId: 173100466
* Windows,JNI: use wstrings onlyGravatar Laszlo Csomor2017-10-20
| | | | | | | | | | | | | | | | | | | | In this commit: - fix the Windows JNI library to only use UTF-16 strings Converting between multi-byte strings (UTF-8) and wstrings (UTF-16) always carries the risk of incorrectly handling the strings. It also takes time, even if not much. Not converting the strings but using the raw Java strings (which are in fact UTF-16 strings) simplifies the code and allows using non-ASCII paths (at least in the JNI module, even if Bazel as a whole doesn't support non-ASCII characters). Change-Id: I827fbe92a1bbefac049a1e34ac1738c965ed2e9c PiperOrigin-RevId: 172715277
* 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
* blaze_util_posix.cc: declare use of dprintfGravatar Klaus Aehlig2017-10-09
| | | | | | | | | | On some systems, the dprintf header is only part of <stdio.h> if requested (to allow compatibility with applications before the standardization of dprintf). As we use dprintf, request it by defining _WITH_DPRINTF. Change-Id: Ia4a80e08760043c5343b4c333b146f4ea87d081b PiperOrigin-RevId: 171409630
* In the launcher, use F_OFD_SETLK if available.Gravatar Googler2017-10-06
| | | | | | | | | | | Because OFD locks are not per-process, F_OFD_GETLK does not report which process holds the lock, so we use the contents of the lock file instead. Works around a Linux kernel bug where POSIX record locks are lost at execve() if any other threads exist. RELNOTES: None. PiperOrigin-RevId: 171209685
* 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
* Delete unused BlazeUtil#SearchNullaryOptionEverywhere.Gravatar lpino2017-09-20
| | | | PiperOrigin-RevId: 169370539
* Windows: Adding default --python_pathGravatar Yun Peng2017-09-14
| | | | | | | | | | | On Windows, Bazel client will try to find python.exe in $PATH. If succeed, then we pretend to add a --python_path option in the least important bazelrc file. Fixed https://github.com/bazelbuild/bazel/issues/3717 Change-Id: I8d97b0895f024d8d236f3b4b39f91c41d947a5fa PiperOrigin-RevId: 168659085
* Remove all #ifdef COMPILER_MSVC from blaze_util_windows.cc.Gravatar Dmitry Lomov2017-09-04
| | | | | | | | | | COMPILER_MSVC is really a misnomer. It really means "use native Win32 APIs instead of Unix emulation (msys)". Since we no longer develop msys-based version, we should remove all #if (windows && !COMPILER_MSVC) sections from the code base. Change-Id: Ibf0f62e4077027b799885c5dcbbce2da626b281c PiperOrigin-RevId: 167392820
* Internal changeGravatar Googler2017-08-30
| | | | PiperOrigin-RevId: 166874758
* Make Windows C++ launcher support long pathGravatar Yun Peng2017-08-29
| | | | | Change-Id: I25795c748fa98b9275ae34ead17fce02a57dc8e4 PiperOrigin-RevId: 166816800
* 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
* Ensure our "Another command is running" messages hold realistic PIDs.Gravatar jmmv2017-08-28
| | | | | | | | | | | | | | | | | | | | Instead of blocking indefinitely for the server lock to become available when other commands are running, busy-wait for the lock to be released. This allows us to detect changes in the PID of the client that is holding the lock, and thus lets us make our wait messages more accurate. There have been multiple bug reports over time (especially from macOS users) where they complain that Bazel is stuck waiting for a non-existent PID. The code doesn't look obviously bogus, so this might just be a case of confusion based on the printed PID. By improving the diagnostic messages we output, we'll either make this confusion go away or have a chance of gathering more data when/if this happens again. This change has the side-effect of homogenizing the wait messages printed by both the Blaze client and the Blaze server and also adds details to know which component is printing what. PiperOrigin-RevId: 166508406
* Update Bazel BUILD file to allow def_parse depend on Bazel specific targets ↵Gravatar pcloudy2017-08-28
| | | | | | from third_party. PiperOrigin-RevId: 166475827
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 00:53:46 +0000