| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
| |
`memcmp(msys_display_name, value, sizeof(msys_display_name)` try to get length of `msys_display_name` with `sizeof`, but `msys_display_name` is declared as `const char*` pointer, so `sizeof` will return the size of pointer (8-bytes) instead of actual length of string. Declare string as `const char msys_display_name[]` will fix this.
Found by Clang's `-Wsizeof-pointer-memaccess`.
/cc @dslomov
Closes #5476.
PiperOrigin-RevId: 202903566
|
|
|
|
| |
PiperOrigin-RevId: 202644968
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit https://github.com/bazelbuild/bazel/commit/f5043d6831ea1c266104363b4e8911eb97f96fbc
was incorrect in that it cached the file names,
not the directory names.
This commit fixes that. I verified that the number
of calls to ExtractBlazeZipProcessor::Process is
greater than the calls to MakeDirectories within
(1038 vs. 172 on Linux).
See https://github.com/bazelbuild/bazel/issues/5444
Change-Id: I314bdc9337c9782a5ceaed7aac785a552b222b1f
Closes #5484.
Change-Id: I314bdc9337c9782a5ceaed7aac785a552b222b1f
PiperOrigin-RevId: 202314400
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a simple profiler that can measure function
call counts and durations, and report statistics
by printing to stderr.
Motivation:
I recently needed a profiler for PR #5445 and
PR #5448, so I'm adding the polished code now.
Usage:
1. depend on //src/main/cpp/util:profiler
2. use StopWatch, Task, and ScopedTask objects
as shown in profiler.h's class documentation
See https://github.com/bazelbuild/bazel/issues/5444
Change-Id: I43f0afd124b486c694f451e8455a66ffca8137b6
Closes #5461.
Change-Id: I43f0afd124b486c694f451e8455a66ffca8137b6
PiperOrigin-RevId: 202314319
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The native launcher can now launch Java and Bash binary in
directory with non-English characters.
Unfortunately, python doesn't support running python zip file under
directory with non-English characters. eg. python ./??/bin.zip will
still fail.
See https://github.com/bazelbuild/bazel/issues/4473
Change-Id: I77fe9cdaabffc2e0d25c7097da5c0c9333a9c4a3
PiperOrigin-RevId: 201939391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When extracting embedded binaries, the client now
caches which directories it has already created
and won't attempt creating them again.
This saves some time on Windows: from 16.3 sec on
average down to 13.2 sec. (n=10 runs, always
starting Bazel with a new --output_user_root and
shutting down afterwards.)
On Linux I see only a marginal speedup, not
significant enough to claim credit for it. :)
See https://github.com/bazelbuild/bazel/issues/5444
Closes #5448.
PiperOrigin-RevId: 201933181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Bazel client on Windows is now 50% faster to
check the embedded tools than it was before.
Results:
- Linux: 20 ms -> 6 ms
- Windows: 294 ms -> 133 ms
Measurements were done with n=10 runs and a hot
server, using blaze::GetMillisecondsMonotonic().
Previously the client performed the same tasks
multiple times while trying to determine if a path
was a good extracted binary. (E.g. converted the
path to Windows format multiple times, checked if
it was a directory twice, opened the path twice.)
Now the client performes these tasks only once,
e.g. it converts path once and stats only once.
See https://github.com/bazelbuild/bazel/issues/5444
Closes #5445.
PiperOrigin-RevId: 201913758
|
|
|
|
|
|
|
|
|
|
|
| |
The master bazelrc is now defined by preprocessor macro at (Bazel's) compile time. The default is still /etc/bazel.bazelrc for most platforms, but windows now has a %ProgramData% relative default value as well. Users wishing to change this default when building Bazel for a new platform should edit BAZEL_SYSTEM_BAZELRC_PATH in src/main/cpp/BUILD.
Part of https://github.com/bazelbuild/bazel/issues/4502, relevant to the duplicate issue #4809.
TESTED: default settings were tested manually, since they cannot be tested in a sandbox
RELNOTES: Windows default system bazelrc is read from the user's ProgramData if present.
PiperOrigin-RevId: 201423446
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we have:
bool AsAbsoluteWindowsPath(const std::wstring& path, std::wstring* result, std::string* error);
This change helps making the C++ native launcher work with UTF-16.
See https://github.com/bazelbuild/bazel/issues/4473
Closes #5406.
Change-Id: I7eaf55f9fe5a4d41e3dd09edc2a21e9b3cc9277c
PiperOrigin-RevId: 201352866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix breakage introduced in #5385 due to incorrect use of `std::move` on local temporary variable after function returns (found by Clang on Windows).
Since `OneYearDelay` function will return the same value and `kOneYear` is only used in one place, remove unused `OneYearDelay` function and move `kOneYear` to `GetFuture` as a `constexpr` constant.
Drive-by improvement: remove some const reference in function signatures. `FILETIME` is a plain C struct with size of 64-bit, so it is trivially-copyable and can easily fit into a 64-bit register. It is more efficient to pass `FILETIME` by value (smaller code size).
/cc @laszlocsomor
Closes #5434.
Change-Id: I136fe4a8ce1b274a80e3206b62e6087dd0f8f5eb
PiperOrigin-RevId: 201343053
|
|
|
|
|
|
|
|
|
|
|
| |
For paths passed to Bazel on the command line, the shell expands these variables, but for hardcoded defaults, we must make the library call ourselves.
We do not add similar support in Posix systems, where it is less common to rely on standard path-related variables.
Prerequisit for issue #4502.
RELNOTES: None.
PiperOrigin-RevId: 201183214
|
|
|
|
| |
PiperOrigin-RevId: 201144030
|
|
|
|
|
|
|
|
| |
Replace with an update at most every 10 seconds if we are still trying to connect.
TESTED: Tested manually that this does print every 10 minutes if the server is prevented from connecting.
RELNOTES: None.
PiperOrigin-RevId: 200764279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel on Windows is now consistent with Bazel on
Unixes, by setting the mtimes of embedded binaries
to 10 years in the future.
Before this change, on Windows, Bazel used to set
these mtimes to CURRENT_YEAR + 10, January 1st.
This meant that if a user ran Bazel on 2017/12/29,
then on Unix Bazel set the mtimes to 2027/12/29
but on Windows it set them to 2027/01/01.
If the user then ran Bazel in the same workspace
on 2018/01/02, on Unixes it worked fine, but on
Windows it detected that the embedded binaries'
mtime is older than 2018/01/01, and reported a
"corrupt installation" error.
Fixes https://github.com/bazelbuild/bazel/issues/4378
Change-Id: I3457bdc360a62a279d1d08c9a69997929f2067dd
Closes #5385.
Change-Id: I3457bdc360a62a279d1d08c9a69997929f2067dd
PiperOrigin-RevId: 200395493
|
|
|
|
|
|
|
|
|
|
|
| |
- Updates the embedded JDK to Azul Zulu 9.0.7
- All integration tests use Bazel with the embedded JDK
Also updated: http://storage.googleapis.com/bazel-mirror/openjdk/index.html
Closes #5312, #5314, #5315
PiperOrigin-RevId: 200055008
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert most `COMPILER_MSVC` to `_WIN32` (as they apply to Windows platform, not MSVC compiler). Only `src/tools/singlejar/zip_headers.h` and `src/main/cpp/util/md5.h` actually need `_MSC_VER`.
`COMPILER_MSVC` in `third_party/protobuf` are not removed. They can be fixed by updating dependency to newer version.
/cc @meteorcloudy
Closes #5350.
Change-Id: Ibc131abfaf34a0cb2bd338549983ea9d28eaabfe
PiperOrigin-RevId: 200019793
|
|
|
|
|
|
|
|
|
| |
It does not claim to, and this was already true for posix platforms. Windows platforms, however, always made the path absolute, which was a hard-to-diagnose difference between the two.
Similarly, MakeAbsolute was relying on this to be correct for windows, so this change splits the implementation and keeps the behavior consistent. While we're here, also remove the empty-string behavior from MakeAbsolute, and instead make it clear at all sites that this behavior is present and affects accepted flag syntax. We may want to remove this later.
RELNOTES: None.
PiperOrigin-RevId: 199663395
|
|
|
|
|
|
|
|
|
|
|
| |
Leave functions that make file accesses in the file library, and general blaze utilities in the blaze_util file, but move the functions that boil down to string manipulation and path formatting to their own file. (With the exception of getCWD, since absolute path syntax is relevant here.)
Doing this largely to consolidate all Windows path control into a single place, so that it's easier to notice inconsistencies. For instance, ConvertPath currently makes Windows paths absolute, but not Posix paths, and MakeAbsolute relies on this behavior. In addition, JoinPath assumes Posix path syntax, which leads to some odd looking paths. These will be fixed in a followup change.
(Found these issues while working on #4502, trying to fix the windows-specific system bazelrc.)
RELNOTES: None.
PiperOrigin-RevId: 199368226
|
|
|
|
|
|
|
|
|
| |
the http_proxy value.
Also change the environment for the client and the server in this case, instead of only changing the server's environment.
RELNOTES: None.
PiperOrigin-RevId: 199152406
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This overrides --bazelrc and --[no]master_bazelrc regardless of order. Like --bazelrc and --[no]master_bazelrc, it cannot be mentioned in an rc file, this would be a contradiction. This flag is useful for testing, and for having a version-agnostic way to turn off all rc files, such as in the canonical command line reporting. Now that blazerc and bazelrc are separate, this is necessary.
If explicit values for --bazelrc or --master_bazelrc are provided which are now ignored, Bazel will warn the user.
#4502
Alternatives considered - We could avoid this flag but would need to have some well-documented, reusable list of the startup flags that effectively come to the same effect. This would be necessary in our integration tests and in the CommandLineEvent and other places where rc files need to be completely disabled for correctness. We decided that this startup option was more straightforward and usable for both users and Bazel devs: it shouldn't be used when more fine-grained control is needed, but provides warnings if users are likely to be confused by the outcome.
RELNOTES: None.
PiperOrigin-RevId: 196750704
|
|
|
|
|
|
|
|
|
| |
Create junctions to jar's directory when java launcher and its jar are under different drives
Fixed https://github.com/bazelbuild/bazel/issues/5135
Change-Id: I21c5b28f5f36c1fe234f8b781fe40d526db846cc
PiperOrigin-RevId: 196477704
|
|
|
|
|
|
| |
and continue to use the embedded JDK as the default host_javabase.
PiperOrigin-RevId: 196471714
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the half-done C++ runfiles library to
`//tools/cpp/runfiles`. (The Python and
Bash runfiles libraries are already under
`//tools/<language>/runfiles`.)
See https://github.com/bazelbuild/bazel/issues/4460
Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7
Closes #5107.
Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7
PiperOrigin-RevId: 194763392
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Bazel CI pipeline (pre and postsubmits) on all platforms: https://buildkite.com/bazel/bazel-bazel/builds/1785
Fixes https://github.com/bazelbuild/bazel/issues/5113
RELNOTES: None.
PiperOrigin-RevId: 194620643
|
|
|
|
| |
PiperOrigin-RevId: 194602500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Bazel client no longer supports MSYS paths.
The only exception is "/dev/null" which the client
treats as "NUL".
After this change you can no longer pass MSYS
paths as Bazel flag values on Windows.
See https://github.com/bazelbuild/bazel/issues/4319
Change-Id: I39d81843015c5a4014dd5953bac2e1c29dcd5bed
PiperOrigin-RevId: 194372504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix error reporting in the path conversion methods
of the Bazel client. Previously the error
reporting logic used GetLastErrorString in places
where it was not appropriate (i.e. it was not a
failed Windows API call that caused an error).
This cleanup prepares removing the concept of the
MSYS root from the Bazel client, since MSYS paths
are no longer supported and we want to cut Bazel's
dependency on Bash (thus MSYS) completely.
See https://github.com/bazelbuild/bazel/issues/4319
Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088
Closes #5072.
Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088
PiperOrigin-RevId: 194052665
|
|
|
|
|
|
|
| |
It's better for testing, while keeping it clear that these functions should not be used outside of option_processor.cc.
RELNOTES: None.
PiperOrigin-RevId: 193947022
|
|
|
|
|
|
|
|
| |
Bazel now has its own subclass of StartupOptions to specify bazel-only options. This is needed for https://github.com/bazelbuild/bazel/issues/4502.
RELNOTES(INC): No longer accepts --blazerc or --[no]master_blazerc, accepts bazelrc name only.
PiperOrigin-RevId: 193718297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the list of rc files a local variable as it need not be a class
attribute, and drop the unused rcoptions_ field.
This is a trivial refactoring and the remaining code is still too
confusing. It'd be worth splitting OptionProcessor in two pieces:
OptionProcessor to exclusively keep the virtual ParseOptions method
and no state, and a new ParsedOptions type to act as the immutable
return value of ParseOptions. This would decouple all state
mutations.
RELNOTES: None.
PiperOrigin-RevId: 193557347
|
|
|
|
|
|
|
| |
In preparation for https://github.com/bazelbuild/bazel/issues/4502, make OptionProcessor::GetRcFiles contain the logic for both the user bazelrcs and the master bazelrcs.
RELNOTES: None
PiperOrigin-RevId: 193521683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change GetHashedBaseDir in the Bazel client on
Windows, to only use an alphabet of 32 characters,
not of 64. The 64-element alphabet contained
effective repetitions because path names on
Windows are case-insensitive.
Fixes https://github.com/bazelbuild/bazel/issues/5053
Change-Id: I2cfb40e32684ff42b95334e08e4d56ee318a57ca
Closes #5054.
Change-Id: I4225fd8a92634ff26ae2154af9298bda33bea6ac
PiperOrigin-RevId: 193507800
|
|
|
|
|
|
|
| |
by "blaze run --direct_run".
RELNOTES: None.
PiperOrigin-RevId: 193391379
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an immediate fix for a very nasty bug:
https://github.com/bazelbuild/bazel/issues/5038
Change-Id: I5e4f9fa13e5ac785514bc0dc4ce6cba9a88f33bb
Closes #5039.
Change-Id: I5e4f9fa13e5ac785514bc0dc4ce6cba9a88f33bb
PiperOrigin-RevId: 193315571
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 192313667
|
|
|
|
|
|
|
| |
Closes #4986.
Change-Id: I81bbec801116ec1f45416bba7a724d7f00b9b00c
PiperOrigin-RevId: 192253687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `d_type` field is not part of the POSIX specification. Added a compile time check to see if we can use it. When not present fallback to a (slightly more expensive) call to 'stat'.
The reason why I need this is because I'm trying to port Bazel to a POSIX compliant platform. Even though my porting effort might fail miserably ;-) I think having a POSIX implementation which is POSIX compliant would be of benefit to the Bazel project.
Besides the POSIX spec I've based the implementation on information I found here:
* https://stackoverflow.com/questions/2197918/cross-platform-way-of-testing-whether-a-file-is-a-directory
* https://stackoverflow.com/questions/23958040/checking-if-a-dir-entry-returned-by-readdir-is-a-directory-link-or-file#answer-29094555
* https://stackoverflow.com/questions/39429803/how-to-list-first-level-directories-only-in-c/39430337#39430337
Closes #4967.
PiperOrigin-RevId: 192102522
|
|
|
|
|
|
|
| |
This will mean the messages will make it to the right output stream.
RELNOTES:
PiperOrigin-RevId: 191925662
|
|
|
|
|
|
|
| |
Will migrate die() instances in a later change, to keep this one clean.
RELNOTES: None.
PiperOrigin-RevId: 191491701
|
|
|
|
|
|
|
|
|
|
|
| |
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
|