| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This refactoring is not currently used in Bazel, but is necessary for our internal variant.
RELNOTES: None
PiperOrigin-RevId: 178947759
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160111047
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149282686
MOS_MIGRATED_REVID=149282686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
RELNOTES: Convert --use_action_cache to a regular option
--
PiperOrigin-RevId: 148804881
MOS_MIGRATED_REVID=148804881
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 141483567
MOS_MIGRATED_REVID=141483567
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
- --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
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137944374
|
|
|
|
|
|
|
| |
to detect whether arg is a valid startup option.
--
MOS_MIGRATED_REVID=137512954
|
|
|
|
|
|
|
|
|
|
|
| |
* remove "using std::" declarations from header files
* add missing "std::" to some string declarations at some header files
* add "using std::string;" to some source files where necessary
--
Change-Id: Ib64f62b5add499d6171fa922227194ac992fa542
Reviewed-on: https://bazel-review.googlesource.com/#/c/6630/
MOS_MIGRATED_REVID=136355671
|
|
|
|
|
|
|
|
|
| |
the Bazel server.
RELNOTES[INC]: --command_port=-1 to use AF_UNIX for client/server communications is not supported anymore.
--
MOS_MIGRATED_REVID=135355673
|
|
|
|
|
|
|
|
|
|
|
| |
This patch integrates the code of Init() function into
StartupOptions's constuctor and thus fixing the TODO
in startup_options.cc.
--
Change-Id: Ic041306387f5ef82fa80d8511c3e9b7be706754a
Reviewed-on: https://bazel-review.googlesource.com/#/c/6332/2
MOS_MIGRATED_REVID=134759417
|
|
|
|
|
|
|
|
| |
Sometimes, especially in the case of a lot of output, one may not want to write
everything twice.
--
MOS_MIGRATED_REVID=133388416
|
|
|
|
|
|
|
|
|
|
| |
Now that we have gotten a StartupOptions class for each of the products
we support, we can bake in the product name in each instance instead of
passing it to the constructor. Helps with encapsulation and simplifies
various instantiations of these classes.
--
MOS_MIGRATED_REVID=133255854
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL is a verbatim reproduction of the following CLs, modulo adjustments
to cope with changes at HEAD:
* commit 4a45d92130a6b1306a3840d006df165b8040a6cf: Use inheritance to support site-specific options.
* commit dfb2c73eda3d2dd8787ea9b2d0a03b49dfa2acc5: Inject the product name via the per-product main.cc files.
* unknown commit: Remove the internal/external startup_options duality.
The cause that triggered the rollbacks was fixed separately in commit 69a8d7205287bedf3a6140ec9327e2fad1758c22
as prepartory work for this roll-forward, so things should work now.
--
MOS_MIGRATED_REVID=133139218
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=132940326
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
commit 4a45d92130a6b1306a3840d006df165b8040a6cf and everything after in [] breaks the Blaze nightlies
*** Original change description ***
Inject the product name via the per-product main.cc files.
Instead of using a compile-time PRODUCT_NAME constant and complex Build
rules to set the correct product name for Blaze and Bazel, use the new
main.cc files to inject the appropriate value.
--
MOS_MIGRATED_REVID=132934596
|
|
|
|
|
|
|
|
|
| |
Instead of using a compile-time PRODUCT_NAME constant and complex Build
rules to set the correct product name for Blaze and Bazel, use the new
main.cc files to inject the appropriate value.
--
MOS_MIGRATED_REVID=132675327
|
|
Rename BlazeStartupOptions to StartupOptions and turn the latter into a
class that can be subclassed to implement site-specific options
behavior. This lends itself to easier customization for the
site-specific versions, especially if there is more than one, and gets
rid of the strange build-time parameterization of the old
blaze_startup_options*.cc files.
Note that this change introduces various TODOs. This is intentional.
This change is quite complex as it is and I want to focus it on
reshuffling the class structure without actually touching the
internals. The latter can be done in subsequent, more targetted
changes that are easier to review and understand.
--
MOS_MIGRATED_REVID=132555032
|