| 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
|
|
|
|
|
|
| |
Closes #4494.
PiperOrigin-RevId: 183380779
|
|
|
|
|
|
|
|
|
| |
ExecuteDaemon() always returns a defined value.
Fixes #4394.
RELNOTES: None.
PiperOrigin-RevId: 181315375
|
|
|
|
|
| |
Change-Id: Ic39712b613a0400f595a7db6e6f957057775b1b8
PiperOrigin-RevId: 178101141
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
The struct timespec consists of a time_t and a long entry.
So provide arguments of correct type, instead of two times
an unsigned int, and explicitly cast appropriately. Fixes
type errors on 32-bit machines. While there, also explicitly
inlcude time.h, required for nanosleep.
Change-Id: I56aabed1cc0c82d93f9c4b9b69d2c9d549207855
PiperOrigin-RevId: 164599502
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel now detects whether it was started from a
command line (or as a subprocess), or from Windows
Explorer (by clicking its icon). In the latter
case it displays an error message asking the user
to run it from a command line, and waiting for a
keypress so the user has time to read this
message.
Change-Id: I4b0430e30d2f1f243cec6ff63cb3abac907e60e3
PiperOrigin-RevId: 163338527
|
|
|
|
|
|
|
|
|
|
|
| |
cinttypes is the C++ header that should replace stdint.h. Not
using the correct header was leading to compilation error on CentOS 6.7
Fixes #3455.
To be cherry-picked for #3375.
Change-Id: I6df22134a4a4902ec9fa7ecdfaeb5408eacf3564
PiperOrigin-RevId: 163334651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic is as follows:
1) search for msys installation
2) search got git-on-Windows installation
3) search in PATH.
This happens on every client startup unless BAZEL_SH enviornment
variable is set.
My measurements show that the time required for this detection is
negligible (<10 msec in the worst case).
Change-Id: If130e2491a9df5a23954d303f2ccdb932eeed1db
PiperOrigin-RevId: 162466913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change ensures that the server process is terminated before the
client process terminates, when evaluating a command that shuts down
the server.
When completing such a command, the server communicates to the client
that the server will terminate itself by setting a termination_expected
bit in the final RunResponse message. The client then waits up to 60s
for the server process to actually terminate. If it does not, then the
client SIGKILLs the server.
Also makes the gRPC server stop accepting new commands before the
shutdown command completes.
Drive-by fix to comments on Search{Un,Null}aryOption.
RELNOTES: Commands that shut down the server (like "shutdown") now ensure that the server process has terminated before the client process terminates.
PiperOrigin-RevId: 161537480
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
A backwards incompatible change for CLI.
RELNOTES: Rollback of https://github.com/bazelbuild/bazel/commit/458990b0c155130e242117e2bfc5ebfdf787d2e2
PiperOrigin-RevId: 161457646
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under macOS, the default soft resource limits for open files and concurrent
processes are pretty low, but their corresponding hard defaults are
reasonable. Because the soft limits are low, Bazel sometimes fails during
large builds -- not because of Bazel itself, but because the executed
actions do "too much work" or because the --jobs setting was high enough
to cause all parallel tasks to exceed the limits.
Instead of trying to fix the actions themselves, start by trying to raise
the system limits as a best-effort operation. And, given that this code
is fairly portable, try to do it on all POSIX systems and not just macOS.
Note that, for non-macOS systems, this might still not do what's promised
in all circumstances because I'm currently only implementing
GetExplicitSystemLimit on macOS.
RELNOTES: None.
PiperOrigin-RevId: 161401482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bazel prints all the progress to stderr, yet the decision to switch between
"smart" and "dumb" output modes is done based on the stdout and stderr
connected terminals. That breaks for a command like this:
bazel query 'something' | wc -l
Even though all the progress is still output to the terminal through stderr,
bazel switches to "dumb" mode, printing progress messages one per line.
It seems reasonable to make the "smart"/"dumb" output mode decision based on
the stderr only.
Tested:
With the change "bazel query '...' | wc -l" prints "smart" progress messages.
RELNOTES: Check stderr to detect if connected to a terminal. Deprecate --isatty.
PiperOrigin-RevId: 161243017
|
|
|
|
|
|
|
|
|
|
| |
if (result != count) {
~~~~~~~^~~~~~~~
Of course, problems arising from this are only theoretical.
Change-Id: Id045a97623026e005d40940eb4a7d30d73f4ce32
PiperOrigin-RevId: 157561218
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 156039435
|
|
|
|
|
|
|
|
|
|
| |
This is so that there is as little room for undesired behavior (e.g.
deadlocks), which can happen when multi-threaded programs fork if the code is
not written *very* carefully. See the comment before ExecuteDaemon() in
blaze_util_posix.cc for an detailed treatise on the matter.
RELNOTES: None.
PiperOrigin-RevId: 155750707
|
|
|
|
|
|
|
|
|
| |
file and not the server.
This is so that the server does as few things as possible before exec() (preferably, nothing) so that we don't accidentally call malloc() which would make it possible to deadlock if the server spawned multiple threads before ExecuteDaemon().
RELNOTES: None.
PiperOrigin-RevId: 155603273
|
|
|
|
|
|
|
|
| |
It does not need to be a fully allocated std::string every time.
A simple character constant is enough for it.
Change-Id: I98b9d4bb77932ea18646fbc793132e089bc66124
PiperOrigin-RevId: 154054987
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bugfixed version of
https://cr.bazel.build/9520 which broke some
Google-internal tests.
This change allows removing duplicate code:
ReadDirectorySymlink was implemented on Windows as
a junction resolver, which is also implemented in
file_windows.cc. Now it uses the JunctionResolver.
RELNOTES: none
PiperOrigin-RevId: 151691895
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create a method in blaze_util_<platform> to
retrieve the path to the home dir ($HOME on
Linux/macOS, %USERPROFILE% on Windows), where we
look for the user's bazelrc file (".bazelrc").
--
Change-Id: I86be1dbe1f992ad55eb09b496024754099d54912
Reviewed-on: https://cr.bazel.build/9513
PiperOrigin-RevId: 151004759
MOS_MIGRATED_REVID=151004759
|
|
|
|
|
|
|
|
| |
This is prone to deadlock.
--
PiperOrigin-RevId: 150263255
MOS_MIGRATED_REVID=150263255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
In this change:
- add TODOs and comments
- inline blaze::ExitImmediately at call sites
--
PiperOrigin-RevId: 142671757
MOS_MIGRATED_REVID=142671757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move GetJvmVersion from blaze_util to
blaze_util_platform, and remove the RunProgram
declaration from blaze_util.h.
Since GetJvmVersion is the only user of RunProgram
this is safe to do, and allows making RunProgram
static as well as simplifying its implementation
on Windows, while also changing it to use
CreateProcessW instead of CreateProcessA.
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 142122045
MOS_MIGRATED_REVID=142122045
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This way we can remove the dependency on blaze_util (which is Bazel's
client specific) from singlejar.
This work was made possible by commit 49970e0136d0: ("Bazel client:
platform-specific {Read,Write}File").
--
Change-Id: I6e95fb9119a271e4d48cbe2eefc1d5354ee188aa
Reviewed-on: https://cr.bazel.build/7650
PiperOrigin-RevId: 141294165
MOS_MIGRATED_REVID=141294165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Final modifications to the Bazel client code so
we can compile //src/main/cpp/...:all using MSVC.
Yay!
We still have some dependencies that don't compile
with MSVC, namely Ijar, build-runfiles,
process-wrapper, and process-tools.
Still, this change is a huge success, because now
we can add regression tests to prevent people from
introducing breaking changes to the client that
would break Windows/MSVC compilation.
It's important to point out that we can only build
this library for now, most functions in
file_windows.cc and blaze_util_windows.cc have an
empty body (they just call `pdie`).
See https://github.com/bazelbuild/bazel/issues/2107
--
MOS_MIGRATED_REVID=140348351
|
|
|
|
|
|
|
|
|
|
| |
Move terminal-querying functions and GetUserName
from blaze_util.cc into blaze_util_<platform>.
See https://github.com/bazelbuild/bazel/issues/2107
--
MOS_MIGRATED_REVID=140346402
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Move blaze::AcquireLock and blaze::ReleaseLock
into blaze_util_<platform>.
See https://github.com/bazelbuild/bazel/issues/2107
--
MOS_MIGRATED_REVID=140200355
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make blaze::ReadFileDescriptor(int fd, ...) and
blaze::WriteFile(int fd, ...) platform-independent
by mocking out the read(2) and write(2) calls.
Also rename ReadFileDescriptor to ReadFrom and
introduce a new WriteTo method that encapsulates
WriteFile's prior logic.
In particular these functions now take a
read_func/write_func function argument instead of
a file descriptor, so the read(2)/write(2) calls
can be mocked out.
This allows us to use these functions on Windows
too, where read(2)/write(2) are not implemented,
and we can inject a different
read_func/write_func.
See https://github.com/bazelbuild/bazel/issues/2107
--
MOS_MIGRATED_REVID=140195973
|
|
|
|
|
|
|
|
|
|
| |
Move the signal handling code from blaze.cc into
blaze_util_<platform>.
See https://github.com/bazelbuild/bazel/issues/2107
--
MOS_MIGRATED_REVID=140134781
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We moved most of the functionality (e.g. _exit,
SetupStreams) into blaze_util_<platform> or
changed to alternative functions (fwrite + stderr
instead of write + STDERR_HANDLE).
This change brings us closer to compiling blaze.cc
with MSVC. We still have to move signal handlers
out of blaze.cc as well as code dealing with the
server PID.
See https://github.com/bazelbuild/bazel/issues/2107
--
MOS_MIGRATED_REVID=140123945
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upon startup the Bazel client checks if there's
already a running server process and if so then
connects to it.
We achieve this by checking if there's a symlink
in the server directory called served.pid,
pointing to /proc/<server_pid>. If so, we read the
symlink's target and extract the PID; otherwise we
check if there's a file in the server's directory
(server.pid.txt) that contains the PID and read it
from there.
Since the PID file is always there, we don't need
the symlink, plus on Windows we don't support
symlinks anyway, which is the real motivation for
this change.
Just ignoring the PID symlink is not enough, we
need to actively delete it so that switching
between Bazel versions (one that writes a PID
symlink and one that doesn't) won't result in
having a symlink and PID file with different
PIDs and clients trying to kill the wrong server
process / not killing one that they should.
See https://github.com/bazelbuild/bazel/issues/2107
--
MOS_MIGRATED_REVID=140117287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this change:
- rename WriteFileToStreamOrDie to
WriteFileToStderrOrDie (since we only ever used it
for stderr)
- replace open/write/read/close operations with
blaze_util::ReadFile/WriteFile
- wrap ToString(getpid()) in a utility function
- move SyncFile to file_<platform>
--
MOS_MIGRATED_REVID=139560397
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=139436876
|
|
|
|
|
|
|
|
|
|
| |
Move the hashed base directory computation logic
into blaze_util_<platform>.cc in order to clean up
the call site and move platform-dependent code out
the client's main file.
--
MOS_MIGRATED_REVID=139319487
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138816624
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Otherwise, it'd only be reaped by init when the client terminates.
--
MOS_MIGRATED_REVID=137502970
|
|
|
|
|
|
|
|
|
|
|
| |
These two functions have no logic inside it, they just return a string, and a
string that does not change, so they might be better expressed as real C/C++
constants. This might as well generate some better (and less) code anyway.
--
Change-Id: I78673c537c17c2665a74c5778e45a4d41a5f7b50
Reviewed-on: https://bazel-review.googlesource.com/#/c/6114
MOS_MIGRATED_REVID=133805201
|
|
|
|
|
|
|
|
| |
- Use an explicit cast to void to tell the compiler that we are intentionally ignoring return values.
- Delete the unused function GetPeerProcessId()
--
MOS_MIGRATED_REVID=132970162
|