| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
It was removed from the java code 4 years ago, mentioning it causes the server to crash at startup.
RELNOTES: None.
PiperOrigin-RevId: 190636455
|
|
|
|
|
|
|
| |
To replace blaze_util::die and blaze_util::pdie as well, FATAL statements need to accept blaze exit codes.
RELNOTES: None.
PiperOrigin-RevId: 190285798
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Closes #4851.
PiperOrigin-RevId: 189897065
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 188744724
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
...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
|
|
|
|
|
|
|
|
|
|
| |
`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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Remove the static kAsciiPropertyBits data from
strings.cc and replace its only reference with
simpler code.
Change-Id: I95fb12b7d4bca4589ae64603b63019ee6e12bfc2
PiperOrigin-RevId: 186295165
|
|
|
|
|
|
|
| |
Fixes MSVC C4311 pointer truncation warning.
Change-Id: Ic64168d620db010717189200c37c419cccac0653
PiperOrigin-RevId: 185653953
|
|
|
|
|
| |
Change-Id: Icbc478f87d622665b16c13c76518087ac089899e
PiperOrigin-RevId: 185645880
|
|
|
|
| |
PiperOrigin-RevId: 185528799
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184865343
|
|
|
|
|
|
|
| |
no-op behavior-wise.
RELNOTES: None
PiperOrigin-RevId: 184843442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 183995676
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Closes #4494.
PiperOrigin-RevId: 183380779
|
|
|
|
|
|
|
| |
`blaze --nomaster_bazelrc --master_bazelrc` now uses the master bazelrc.
RELNOTES: None
PiperOrigin-RevId: 183083839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Fixed https://github.com/bazelbuild/bazel/issues/4408
Change-Id: Id62b25e675822bbed91a448e70bdcb76e722721e
PiperOrigin-RevId: 181591585
|
|
|
|
|
|
|
|
|
| |
ExecuteDaemon() always returns a defined value.
Fixes #4394.
RELNOTES: None.
PiperOrigin-RevId: 181315375
|
|
|
|
|
|
| |
This refactoring is not currently used in Bazel, but is necessary for our internal variant.
RELNOTES: None
PiperOrigin-RevId: 178947759
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 178641317
|
|
|
|
|
|
| |
[-Wreturn-type]".
PiperOrigin-RevId: 178115185
|
|
|
|
|
| |
Change-Id: Ic39712b613a0400f595a7db6e6f957057775b1b8
PiperOrigin-RevId: 178101141
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This will enable an easier transition from checked-in BUILD files to ones generated by copybara.
RELNOTES: None
PiperOrigin-RevId: 177514519
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 177420511
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--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
|
|
|
|
|
|
|
| |
more intelligible.
RELNOTES: None.
PiperOrigin-RevId: 173512953
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/3938
Change-Id: Ic837f1b97cf8469434118f2660fb15d14c035a14
PiperOrigin-RevId: 173100466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|