aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/cpp/blaze_util_platform.h
Commit message (Collapse)AuthorAge
* 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
* Emit Blaze server pid when there is a connection timeout.Gravatar felly2017-11-30
| | | | | RELNOTES: None PiperOrigin-RevId: 177420511
* Windows: Adding default --python_pathGravatar Yun Peng2017-09-14
| | | | | | | | | | | 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
* Windows: detect if started from Windows ExplorerGravatar Laszlo Csomor2017-07-28
| | | | | | | | | | | | | 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
* Include <cinttypes> instead of <stdint.h>Gravatar Damien Martin-Guillerez2017-07-27
| | | | | | | | | | | 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
* Implement bash.exe detection logic.Gravatar Dmitry Lomov2017-07-19
| | | | | | | | | | | | | | | | 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
* Ensure that shutdown commands end the server process before completionGravatar mschaller2017-07-12
| | | | | | | | | | | | | | | | | | | | 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
* Automated rollback of commit 458990b0c155130e242117e2bfc5ebfdf787d2e2.Gravatar Googler2017-07-11
| | | | | | | | | *** Reason for rollback *** A backwards incompatible change for CLI. RELNOTES: Rollback of https://github.com/bazelbuild/bazel/commit/458990b0c155130e242117e2bfc5ebfdf787d2e2 PiperOrigin-RevId: 161457646
* Raise the maximum number of processes and open files to their maximum.Gravatar jmmv2017-07-11
| | | | | | | | | | | | | | | | | | | 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
* Look at stderr for terminal detection.Gravatar Googler2017-07-10
| | | | | | | | | | | | | | | | | | | | 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
* cpp: turn ListSeparator() function into a constantGravatar Thiago Farina2017-04-25
| | | | | | | | 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
* Bazel client, Windows: impl. client-level lockingGravatar laszlocsomor2017-04-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement blaze::AcquireLock and ReleaseLock. These methods implement the Bazel client-level locking, whose purpose is to detect concurrently running Bazel instances attempting to write to the same output directory. The Bazel server also detects this case (see BlazeCommandDispatcher) but the client needs to start the server first, meaning this cannot detect races between clients that are in the middle of installing. You can see this locking in effect if you run `bazel --output_user_root=/c/foo build src:bazel` in one terminal, then run `bazel --output_user_root=/c/foo help` in another but the same working directory. The second one will say "Another command is running." See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2647 RELNOTES: none PiperOrigin-RevId: 152919185
* Bazel client: simplify ReadDirectorySymlinkGravatar laszlocsomor2017-03-31
| | | | | | | | | | | | | | | 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
* Bazel client, Windows: implement GetHomeDir Gravatar László Csomor2017-03-23
| | | | | | | | | | | | | 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
* Bazel client: make jvm.log path platform-safe Gravatar László Csomor2017-02-24
| | | | | | | | | | | | | | | | | 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
* Bazel client: split CanAccess to specific methodsGravatar Laszlo Csomor2017-01-11
| | | | | | | | | | | | | | 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
* Bazel client: add comments, delete dead codeGravatar Laszlo Csomor2016-12-22
| | | | | | | | | | In this change: - add TODOs and comments - inline blaze::ExitImmediately at call sites -- PiperOrigin-RevId: 142671757 MOS_MIGRATED_REVID=142671757
* Bazel client: generalize path handlingGravatar Laszlo Csomor2016-12-19
| | | | | | | | | | | | | | 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
* Bazel client: get rid of RunProgramGravatar Laszlo Csomor2016-12-15
| | | | | | | | | | | | | | | | | | 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
* move MakeDirectories() into file_platform.hGravatar Thiago Farina2016-12-07
| | | | | | | | | | | | | | 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
* Bazel client: add/remove include statementsGravatar Laszlo Csomor2016-12-06
| | | | | | -- PiperOrigin-RevId: 141157873 MOS_MIGRATED_REVID=141157873
* Bazel client: make it compile with MSVCGravatar Laszlo Csomor2016-11-28
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Bazel client: more platform-specific logicGravatar Laszlo Csomor2016-11-28
| | | | | | | | | | 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
* Bazel client: platform-dependent signal handlingGravatar Laszlo Csomor2016-11-24
| | | | | | | | | | Move the signal handling code from blaze.cc into blaze_util_<platform>. See https://github.com/bazelbuild/bazel/issues/2107 -- MOS_MIGRATED_REVID=140134781
* Bazel client: depend less on <unistd.h>Gravatar Laszlo Csomor2016-11-24
| | | | | | | | | | | | | | | | | 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
* Bazel client: reduce dependency on POSIX APIGravatar Laszlo Csomor2016-11-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Bazel client: reduce dependency on <unistd.h>Gravatar Laszlo Csomor2016-11-18
| | | | | | | | | | | | | | | | | | 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
* Bazel client: no more `stat` usageGravatar Laszlo Csomor2016-11-17
| | | | | -- MOS_MIGRATED_REVID=139436876
* Bazel client: platform-dependent GetHashedBaseDirGravatar Laszlo Csomor2016-11-16
| | | | | | | | | | 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
* C++ refactor: time getters now return millisecondsGravatar Laszlo Csomor2016-11-08
| | | | | | | | | | | | | | Previously they returned nanoseconds but all call sites converted those to milliseconds. This is not only a simplification of the semantics and renaming of the methods to make the returned units and the purpose clear, but also preparation for the Windows/MSVC implementations of these methods. -- MOS_MIGRATED_REVID=138383956
* cpp: header hygienizationGravatar Thiago Farina2016-10-18
| | | | | | | | | | | * 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
* Roll back commit a34c4febbbdfba6c045598101ca9a491cfde7dd9 in favor of not ↵Gravatar Lukacs Berki2016-09-14
| | | | | | | | | verifying the identity of the process killed on interrupt. When the server dies, the client follows soon after, so this is kind of OK. -- MOS_MIGRATED_REVID=133110872
* More client fixes:Gravatar Lukacs Berki2016-09-13
| | | | | | | | - 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
* Mark output_base and output_user_root to not be backed up by TimeMachine on ↵Gravatar Dave MacLachlan2016-07-20
| | | | | | | | | | | Darwin. This is equivalent to what Xcode does with the directories that it generates as part its builds. fix for https://github.com/bazelbuild/bazel/issues/1514 -- MOS_MIGRATED_REVID=127927131
* Fixed repository.which() on WindowsGravatar Yun Peng2016-07-15
| | | | | | | | | Also removed previous workaround in cc_configure.bzl -- Change-Id: I6dcd039fc5e18af8f2d21969641d6bbd05c8badc Reviewed-on: https://bazel-review.googlesource.com/#/c/4034 MOS_MIGRATED_REVID=127518922
* Only tell the user that an old server process was killed if it actually was.Gravatar Lukacs Berki2016-07-14
| | | | | -- MOS_MIGRATED_REVID=127319649
* Remove the check for the existence of the server process in the signal ↵Gravatar Lukacs Berki2016-06-21
| | | | | | | | | handler in the client. This makes Ctrl-C work on Windows somewhat: in particular, in non-batch mode and while no actions are running. -- MOS_MIGRATED_REVID=125318172
* Linux-specific: check if the stray server process we are about to kill -9 is ↵Gravatar Lukacs Berki2016-05-02
| | | | | | | | | | | actually a server process. This should be implemented for other OSes, too, but OS X seems to lack a procfs and it's not clear how to discover anything about a process based on its PID and of course, Windows is a wholly different cup of tea. More work for #930. -- MOS_MIGRATED_REVID=121262673
* Various cleanups and refactorings in the client:Gravatar Lukacs Berki2016-05-02
| | | | | | | | | | | | - Made the control flow much simpler and more understandable - Added some documentation about the interplay of the client and the server - Abstracted out POSIX mechanisms from blaze.cc so that they can be implemented properly on Windows - Added assertions that the methods on BlazeServer are called when they should be Polish for #930. -- MOS_MIGRATED_REVID=121256601
* Acquire the server lock even if the client uses gRPC.Gravatar Lukacs Berki2016-04-28
| | | | | | | | | This is so that only one server instance is started up if two clients are started in a workspace that doesn't have a running server yet. More work towards #930. This may break Windows in case flock() doesn't work there as expected. In anticipation of this, locking is moved to blaze_util_platform.h / blaze_util.cc . -- MOS_MIGRATED_REVID=121013078
* Use the Win32 API to create and query junctions in the C++ client.Gravatar Lukacs Berki2016-04-28
| | | | | | | | | This change makes it possible to build Bazel with itself in server mode. Progress towards #930 . Does not completely fix it because there are still a bunch of issues that need to be taken care of, but it's usable. -- MOS_MIGRATED_REVID=120994369
* cpp: fix "commom" typo in AddLoggingArgs() documentationGravatar Thiago Farina2016-04-27
| | | | | | | | | | | | The correct spelling of it, is, of course, "common". While at this, this also fix a mistaken usage of "from" instead of "form" in ConvertPath() documentation. -- Change-Id: If93984b57da0c98b6dfe4ca70fd4158bd9e1a861 Reviewed-on: https://bazel-review.googlesource.com/#/c/3500 MOS_MIGRATED_REVID=120921796
* Use native process control on Windows to launch subprocesses.Gravatar Lukacs Berki2016-04-27
| | | | | | | | | This is necessary because msys2 signals don't work on native Win32 processes, for example, java.exe . Forcefully terminating the process still doesn't work because it uses signals. It's a-coming. -- MOS_MIGRATED_REVID=120903711
* Revert server.pid to be a symlink so that old server version can shut down ↵Gravatar Lukacs Berki2016-04-26
| | | | | | | | | new ones. Add server.pid.txt that contains the same information in text form. ExecuteDaemon() on Windows will simply not write server.pid . -- MOS_MIGRATED_REVID=120802055
* Factor out various ways to execute subprocesses into separate functions.Gravatar Lukacs Berki2016-04-25
| | | | | | | This is so that they can be implemented properly for Windows. For now, though, they are left in blaze_util.cc since the Windows implementations aren't there yet. -- MOS_MIGRATED_REVID=120709884
* Windows: use junctions to link to installation directory.Gravatar Dmitry Lomov2016-02-19
| | | | | | | | | | Win32 have no good API for that (basically we need to resort to ioctl call). Shelling out to mklink. Needed for #276. -- MOS_MIGRATED_REVID=115040968
* Rationalize copyright headersGravatar Damien Martin-Guillerez2015-09-25
| | | | | | | | | | | The headers were modified with `find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'` And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan. The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand. -- MOS_MIGRATED_REVID=103938715
* Avoid command line argument mangling on Windows.Gravatar Dmitry Lomov2015-08-12
| | | | | | | | | | | | | | exec(3) under mingw converts every command line argument that looks like Unix path into Windows path when executing non-mingw images (criteria for non-mingw image is that the image does not depend on msys-<version>.dll). This affects bazel labels (`//foo:bar` becomes `/foo:bar` for example). This CL: 1) Replaces usage of execv(3) with Windows-native CreateProcess. 2) Converts all command line arguments that are indeed paths into Windows paths. -- MOS_MIGRATED_REVID=100386350
* Update include guards.Gravatar Han-Wen Nienhuys2015-05-15
| | | | | -- MOS_MIGRATED_REVID=93413161
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 06:01:05 +0000