aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/cpp
Commit message (Collapse)AuthorAge
* Create BAZEL_DIE macro.Gravatar ccalvarin2018-04-03
| | | | | | | Will migrate die() instances in a later change, to keep this one clean. RELNOTES: None. PiperOrigin-RevId: 191491701
* Make the client's java startup command line list all startup options.Gravatar ccalvarin2018-03-30
| | | | | | | | | | | We expect that the client passes all startup options to the server, default or explicit. The server's listing of default values should not matter. Yet for a number of these options, the default value in the server was relied upon, because the server command line was not constructed with the client's default value included. Fix visible cases of this, long term this should be tested for, so the invariant is not broken again. This has been the documented expectation for a long time, but a number of violations have crept up over time. Update the comments that lead to this expectation to be more realistic. Add debug statement that shows which options are changed when startup options cause the server to be restarted. The detailed logs will only be seen if --client_debug is set to TRUE. RELNOTES: None. PiperOrigin-RevId: 191066983
* Remove pdie.Gravatar ccalvarin2018-03-29
| | | | | | | pdie and die are pretty similar, pdie just adds the errno string or equivalent from GetLastErrorString(). Make this explicit. This makes message formatting more clear in preparation for moving these all to BAZEL_LOG. RELNOTES: None. PiperOrigin-RevId: 190957255
* Remove startup JVM version checkGravatar cushon2018-03-29
| | | | | | | | | | | | This was added during the JDK 7->8 transition to improve the diagnostic when an older-than-supported host_javabase was used. The version number handling doesn't work with JDK 9 (see [1]), and using Bazel binaries with a bundled host_javabase avoid the error entirely so the message is less important. [1] http://openjdk.java.net/jeps/223 PiperOrigin-RevId: 190944476
* 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
* Fold in warning and error output into client logging.Gravatar ccalvarin2018-03-23
| | | | | | | To replace blaze_util::die and blaze_util::pdie as well, FATAL statements need to accept blaze exit codes. RELNOTES: None. PiperOrigin-RevId: 190285798
* Update the client's skeleton logging framework to use it for --client_debug.Gravatar ccalvarin2018-03-21
| | | | | | | | | We are still unable to turn this on to write to files, but there are currently 2 logging systems in use in the client: the inactive one, and the print-to-stderr option triggered by --client_debug. Combine these, so we can use the same logging format for both. Also combine it with the VerboseLogging functionality - it was not documented anywhere and seems redundant. RELNOTES: None. PiperOrigin-RevId: 189979051
* blaze.cc: Remove unused had_to_wait variableGravatar David Ostrovsky2018-03-21
| | | | | | Closes #4851. PiperOrigin-RevId: 189897065
* Automated rollback of commit 8a5a0a3ed1e19768b6ee024189307bb4ac27460d.Gravatar laszlocsomor2018-03-21
| | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** breaks building //src:bazel *** Original change description *** runfiles,C++: move to //tools/cpp/runfiles Move the C++ runfiles library to the location of the rest of the C++ tools. Also change the C++ namespace to reflect the directory hierarchy. We have not yet announced nor released the C++ runfiles library so these refactorings are fine. See https://github.com/bazelbuild/bazel/issues/4460 Closes #4873. PiperOrigin-RevId: 189883066
* runfiles,C++: move to //tools/cpp/runfilesGravatar Laszlo Csomor2018-03-21
| | | | | | | | | | | | | | | | | | Move the C++ runfiles library to the location of the rest of the C++ tools. Also change the C++ namespace to reflect the directory hierarchy. We have not yet announced nor released the C++ runfiles library so these refactorings are fine. See https://github.com/bazelbuild/bazel/issues/4460 Closes #4873. Change-Id: I1732ef1eaff880cae05b7d218a3b1c0461a6b029 PiperOrigin-RevId: 189874201
* Automated rollback of commit c2b332b45e6ea41a14ecbd3c5f30782bcdeec301.Gravatar laszlocsomor2018-03-14
| | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Causes https://github.com/bazelbuild/bazel/issues/4847 *** Original change description *** windows: replace custom JunctionResolver 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. PiperOrigin-RevId: 189031288
* Prefix startup dots with "Connecting to local Bazel server..." message.Gravatar ruperts2018-03-12
| | | | | RELNOTES: None. PiperOrigin-RevId: 188744724
* Add unit tests for rc parsing.Gravatar ccalvarin2018-03-08
| | | | | | | | | | | | | | | | | These provide some testing for the following cases: - tokenization - recognizing comments - grouping of different lines by command - import ordering - import cycles - bad imports There's still room for more, in particular in the multi-command case, but this feels like a good start. Also identified some surprising behaviors that should be fixed. Leaving them tested as documentation of their broken nature. RELNOTES: None. PiperOrigin-RevId: 188355929
* Convert static std::set to constexpr arrayGravatar Loo Rong Jie2018-03-01
| | | | | | | | | | | | | Google C++ Style Guide disallows static variable with non-trivial destructor. Use constexpr for static variable whenever possible. std::array would make the code cleaner, but MSVC's implementation of constexpr std::array is buggy. Side-benefit: linear search is faster when array is small (<20). Change-Id: Ic8244dcb868e27d02ceb5298ccec482e7d4254b7 PiperOrigin-RevId: 187451495
* runfiles,C++: implement manifest-based runfilesGravatar Laszlo Csomor2018-02-28
| | | | | | | | | | | | | | | | Implement a manifest-based Runfiles object, add tests and test utils (MockFile). Subsequent commits will add more feataures: - creating list of envvars to pass to child processes - automatic Runfiles creation based on argv[0] and the envvars of this process See https://github.com/bazelbuild/bazel/issues/4460 Change-Id: I4376ede3ac00241688ff16a36ed596fb08f13a72 PiperOrigin-RevId: 187318502
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 12:12:40 +0000