aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/cpp
Commit message (Collapse)AuthorAge
* Bazel client, Windows: impl. server->IsStillAliveGravatar Laszlo Csomor2017-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | Implement proper aliveness check for the Bazel server. This allows detecting a server death that occurs after the Java process started but before it started the gRPC server. On other platforms we open an anonymous pipe, let the server inherit the writing end, close the writing end in the client, and attempt to read non-blockingly in order to check if the server is still alive. This approach fails on Windows because anonymous pipes are always blocking. Named pipes support asynchronous access but it's much simpler to just check if the process exited. GetProcessTimes looks like a reliable way to do so, and that's what we use on Windows now. Fixes https://github.com/bazelbuild/bazel/issues/2817 Change-Id: Ic24577d8440eb0c8188c852e2501ce1e254ba9fd PiperOrigin-RevId: 154283585
* 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
* cpp: remove unncessary function prototypesGravatar Thiago Farina2017-04-24
| | | | | | | | It is not necessary to have these function declarations (prototypes) because they are declared+defined before they are actually called. Change-Id: I32d9ba82e056e368eecc553569231ad1174ad5e0 PiperOrigin-RevId: 154035760
* Internal changeGravatar Googler2017-04-24
| | | | PiperOrigin-RevId: 154017157
* Add a custom single-line formatter for java.log.Gravatar schmitt2017-04-13
| | | | | | | | 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
* 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
* Avoid false positive uninitialized variable use warning in blaze.ccGravatar Peter Foley2017-04-11
| | | | | | | fprintf(stderr, "\nCannot write to %s; exiting...\n\n", broken_pipe_name); Closes #2736. PiperOrigin-RevId: 152675241
* Fix possible parsing of same rc file multiple times.Gravatar lpino2017-04-07
| | | | | | | Write a new function that dedupes a set of paths using its canonical form and use it to remove possible duplicates in the set of rc files that will be parsed. PiperOrigin-RevId: 152489149
* Move InvocationPolicy from a startup argument to part of the RunRequest proto.Gravatar ccalvarin2017-04-07
| | | | | | | | | The user interface is not changing. The policy will still be accepted as a flag passed to the client, as a startup flag (before the command), it will just no longer trigger server restarts and will not be passed on to a bazel server as part of the startup arguments. In batch mode, however, it will still be a startup argument, because the RunRequest proto is not sent, and all invocations restart bazel in batch mode anyway. Since invocation policy only affects command arguments, and changes in command arguments do not cause server restarts, this is consistent with other server restart behavior. RELNOTES: Changing --invocation_policy will no longer force a server restart. PiperOrigin-RevId: 152426207
* 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: fix version check []Gravatar laszlocsomor2017-03-29
| | | | | | | GetVersionEx is discouraged by MSDN, so use the recommended method to check the Windows version. PiperOrigin-RevId: 151553827
* Remove configurability of abrupt exit code behavior.Gravatar ccalvarin2017-03-29
| | | | | | | | 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
* Bazel client, Windows: path casing bugfixes Gravatar László Csomor2017-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | Change blaze::ConvertPath to lower-case its result for sake of deterministic comparison later. Change blaze::CompareAbsolutePaths to call blaze::ConvertPath before comparison. The ConvertPath method normalizes its input then converts it to lowercase, meaning ConvertPath("c:/Foo") and ConvertPath("C:\FOO\.") will give the same result. Thanks to this we will no longer kill the Bazel server if the --output_user_root changes but only in casing, or by adding/removing trailing slash/backslash. Fixes https://github.com/bazelbuild/bazel/issues/2714 -- Change-Id: I36c13378a9e3567862ee1c611f56b0c3ab465da8 Reviewed-on: https://cr.bazel.build/9517 PiperOrigin-RevId: 151425571 MOS_MIGRATED_REVID=151425571
* Make Search{Unary,Nullary}Option skip the rest of the args if "--" is found.Gravatar Luis Fernando Pino Duque2017-03-27
| | | | | | -- PiperOrigin-RevId: 151145409 MOS_MIGRATED_REVID=151145409
* 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, Windows: fix MSYS root computation Gravatar László Csomor2017-03-23
| | | | | | | | | | | | | | Make it more robust: it now works with Cygwin too, e.g. BAZEL_SH=c:/cygwin64/bin/bash.exe See https://github.com/bazelbuild/bazel/issues/2725 Related to https://github.com/bazelbuild/bazel/issues/2447 -- Change-Id: I911f09acd3e39c7cd0fe0750774fa0a900ffd844 Reviewed-on: https://cr.bazel.build/9510 PiperOrigin-RevId: 150885982 MOS_MIGRATED_REVID=150885982
* Implement SigPrintf on Windows.Gravatar Dmitry Lomov2017-03-22
| | | | | | | | -- Change-Id: I6ff757500085daa4c440a3ef41d02e6c664b9f3d Reviewed-on: https://cr.bazel.build/9466 PiperOrigin-RevId: 150857712 MOS_MIGRATED_REVID=150857712
* Handle Ctrl+C / Ctrl+Break on Windows. Gravatar Dmitry Lomov2017-03-22
| | | | | | | | | | | Using ::SetConsoleCtrlHanlder() Win32 API. Tested manually (not sure how to test this automatically :() -- Change-Id: Ibb5b311d6412d77d16a7f7c1658a9f3435d3cd55 Reviewed-on: https://cr.bazel.build/9464 PiperOrigin-RevId: 150760724 MOS_MIGRATED_REVID=150760724
* Bazel client, Windows: ignore dead server processGravatar Laszlo Csomor2017-03-21
| | | | | | | | | | | | | | | | | | | Do not attempt to kill the server process if it's already dead. This gets rid of the spurious "Could not terminate process (Access Denied)" errors, which we got for attempting to TerminateProcess twice (without checking whether the process was still alive), because we apparently assumed that if we can get a HANDLE to the process then it must be alive, which is not true. This is a follow-up to unknown commit. Fixes https://github.com/bazelbuild/bazel/issues/2684 -- PiperOrigin-RevId: 150735254 MOS_MIGRATED_REVID=150735254
* Bazel client, Windows: fix server kill failuresGravatar Laszlo Csomor2017-03-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the (spurious) error messages about the Bazel client's failure to kill the server process, with "Access Denied" errors. This was caused by our attempt to kill the server process twice, and the error was coming from the second attempt. The culprit was an unimplemented VerifyServerProcess method (which ensures that the PID read from the server.pid.txt indeed refers to a running Bazel server) which always returned false, to avoid accidentally killing an unrelated process that got the same PID as the last alive Bazel server. The new code follows the same logic as the Linux version of Bazel, namely storing the process' start time in a file next to the PID file, and checking that the process with said PID was indeed started at the time we read from the file. This change also fixes a problem that the now working VerifyServerProcess uncovered: we need to wait for the previous Bazel server to properly shut down before we can open the new jvm.out log file. Fixes https://github.com/bazelbuild/bazel/issues/2684 -- PiperOrigin-RevId: 150632429 MOS_MIGRATED_REVID=150632429
* Rollback of commit b88e9f3ea66fa839185e88de7dad3e6af0b403b4.Gravatar Laszlo Csomor2017-03-21
| | | | | | | | Roll forward commit ae4b02fb21772effd6836599a7e1792b26ff95e0. -- PiperOrigin-RevId: 150627891 MOS_MIGRATED_REVID=150627891
* Build a version of Bazel with a bundled OpenJDK inside the binary.Gravatar Philipp Wollermann2017-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rollback of commit ae4b02fb21772effd6836599a7e1792b26ff95e0.Gravatar Yun Peng2017-03-17
| | | | | | | | | | | | *** Reason for rollback *** Broken MSVC Bazel build on CI https://github.com/bazelbuild/bazel/issues/2695 -- PiperOrigin-RevId: 150423895 MOS_MIGRATED_REVID=150423895
* Bazel client, Windows: support colorful outputGravatar Laszlo Csomor2017-03-16
| | | | | | | | See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 150314355 MOS_MIGRATED_REVID=150314355
* Bazel client, Windows: fix console handling bugsGravatar Laszlo Csomor2017-03-16
| | | | | | | | | | | | | | | | Fix 3 bugs in blaze_util_windows: - off-by-one error in the loop ensuring the std handles are all open - don't auto-close stdout's HANDLE after querying the console window's size - error-handling for when stdout is redirected thus ::GetStdHandle returns an invalid handle See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 150310578 MOS_MIGRATED_REVID=150310578
* Catch attempts to fork from a multithreaded bazel launcher process.Gravatar Googler2017-03-16
| | | | | | | | This is prone to deadlock. -- PiperOrigin-RevId: 150263255 MOS_MIGRATED_REVID=150263255
* Bazel client, Windows: support "d:/" output rootGravatar Laszlo Csomor2017-03-16
| | | | | | | | | | | | | Support drive roots as --output_user_root values, so "d:\" and "d:/" will now work. However "d:" doesn't work yet because that's shorthand for the current working directory on "D:". See https://github.com/bazelbuild/bazel/issues/2683 -- PiperOrigin-RevId: 150203657 MOS_MIGRATED_REVID=150203657
* windows: Don't try to breakaway from an existing Job in batch mode.Gravatar Philipp Wollermann2017-03-16
| | | | | | | | | | | | | | | | | | | | | | | | Reasoning: It never worked anyway, because Bazel didn't set the JOB_OBJECT_LIMIT_BREAKAWAY_OK limit on its job. This is why running Bazel in batch mode inside a shell integration test on Windows caused a "CreateProcess() failed: access denied" error. By no longer using CREATE_BREAKAWAY_FROM_JOB, this will instead cause us to use nested jobs, which is exactly the right thing to do: - If our parent dies, we and our children still get reliably killed. - But if *only* we die, then just our children will be reliably killed. If we're on an older Windows that doesn't support nested jobs and are running inside an existing job, we should assume that our parent handles process management - for example like Bazel, which runs all spawned processes in their own job. Also remove the CREATE_NEW_PROCESS_GROUP flag in Bazel's batch mode, because I can't see how this makes sense for a non-daemon process. -- PiperOrigin-RevId: 150194586 MOS_MIGRATED_REVID=150194586
* Bazel client, Windows: can connect to fresh serverGravatar Laszlo Csomor2017-03-14
| | | | | | | | | | | | | Fix the bug that the MSYS-less client couldn't connect to the freshly started server and had to be started again. Fixes https://github.com/bazelbuild/bazel/issues/2672 See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 150069285 MOS_MIGRATED_REVID=150069285
* Bazel client, Windows: make server mode work Gravatar Laszlo Csomor2017-03-14
| | | | | | | | | | | | | | | | Fix blaze_util_windows::ConvertAbsolutePaths, which happens to have been the culprit why the MSYS-less Bazel would always kill the running server. Fixes https://github.com/bazelbuild/bazel/issues/2672 See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: I873a78c737a6d6906ac7db9bcd0e7186e17bd7ca Reviewed-on: https://cr.bazel.build/9355 PiperOrigin-RevId: 150052180 MOS_MIGRATED_REVID=150052180
* Increase log size limit to 10M.Gravatar Julio Merino2017-03-10
| | | | | | | | | | 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
* Bazel client, Windows: CreateDirectoryW path limitGravatar Laszlo Csomor2017-03-09
| | | | | | | | | | | | | | | Fix the path limit for non-UNC-prefixed paths when using CreateDirectoryW. According to MSDN [1], this is only 248 chars, as opposed to the usual 260 (MAX_PATH). See https://github.com/bazelbuild/bazel/issues/2107 [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363855(v=vs.85).aspx -- PiperOrigin-RevId: 149627964 MOS_MIGRATED_REVID=149627964
* Bazel client: use PathAsJvmFlag for JVM flagsGravatar Laszlo Csomor2017-03-09
| | | | | | | | | | | | | | | | | 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
* Make Bazel build with MSVC-default-toolchain Bazel Gravatar Yun Peng2017-03-08
| | | | | | | | | | | | | After this change, a msys bazel can be built with a MSVC-default Bazel by adding --cpu=x64_windows_msys --host=x64_windows_msys See https://github.com/bazelbuild/bazel/issues/2627 -- Change-Id: Iaa82bf4dd911c5740b98d3b2739dfccca6203f79 Reviewed-on: https://cr.bazel.build/9293 PiperOrigin-RevId: 149532274 MOS_MIGRATED_REVID=149532274
* Uppercase some hand-selected environment variable names on Windows/MSVC.Gravatar Dmitry Lomov2017-03-08
| | | | | | | | -- Change-Id: Ie1f3be6258f024d352ff4571a5355660f409f70d Reviewed-on: https://cr.bazel.build/9291 PiperOrigin-RevId: 149470780 MOS_MIGRATED_REVID=149470780
* Env.vars: server won't ignore the client envGravatar Dmitry Lomov2017-03-08
| | | | | | | | | | | | | | | | | | Make the --ignore_client_env flag a no-op. The client will pass --client_env flags to the server even in --batch mode. This simplifies the code as well as ensuring that the server always uses the up-do-date client environment. We'll gradually get rid of all System.getenv calls in the server, because the server should always respect the client env. Roll forward of 149403129 with fixes. -- PiperOrigin-RevId: 149435060 MOS_MIGRATED_REVID=149435060
* Rollback of commit 94d8f4e9c8c8757aa7ab7c1a7c3e9afb34039127.Gravatar Klaus Aehlig2017-03-07
| | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** broke //src/test/shell/bazel:bazel_bootstrap_distfile_test *** Original change description *** Env.vars: server won't ignore the client env Make the --ignore_client_env flag a no-op. The client will pass --client_env flags to the server even in --batch mode. This simplifies the code as well as ensuring that the server always uses the up-do-date client environment. We'll gradually get rid of all System.getenv calls in the server, because the server should always respect the client env. -- PiperOrigin-RevId: 149416602 MOS_MIGRATED_REVID=149416602
* Env.vars: server won't ignore the client envGravatar Laszlo Csomor2017-03-07
| | | | | | | | | | | | | | | | Make the --ignore_client_env flag a no-op. The client will pass --client_env flags to the server even in --batch mode. This simplifies the code as well as ensuring that the server always uses the up-do-date client environment. We'll gradually get rid of all System.getenv calls in the server, because the server should always respect the client env. -- PiperOrigin-RevId: 149403129 MOS_MIGRATED_REVID=149403129
* Use the correct path when generating the command-line on Windows.Gravatar Philipp Wollermann2017-03-07
| | | | | | | | We already constructed it in the code via blaze_util::AsShortWindowsPath, but accidentally didn't use the results. -- PiperOrigin-RevId: 149398556 MOS_MIGRATED_REVID=149398556
* Bazel client, Windows/MSVC: fix path handling bugsGravatar Laszlo Csomor2017-03-07
| | | | | | | | | | | | | | | | | | | | Fix blaze_util_windows.ConvertPath: in the MSVC version this is using the actual %PATH% value, we don't need to convert it. Fix blaze_util_windows.PathAsJvmFlag: shorten the path so we can pass it to the JVM process (long paths aren't understood by the shell), but also converrt backslashes to forward slashes so the JVM won't believe we are passing paths with escaped characters. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 149396971 MOS_MIGRATED_REVID=149396971
* Bazel client, Windows: fix compilation bugGravatar Laszlo Csomor2017-03-06
| | | | | | | | This was breaking the CI. -- PiperOrigin-RevId: 149300839 MOS_MIGRATED_REVID=149300839
* Bazel client, Windows: fix ReadFile("/dev/null")Gravatar Laszlo Csomor2017-03-06
| | | | | | | | | | | Mimic read(2) behavior when reading from /dev/null and always successfully read 0 bytes. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 149286494 MOS_MIGRATED_REVID=149286494
* Bazel client, Windows: fix AsShortWindowsPathGravatar Laszlo Csomor2017-03-06
| | | | | | | | | | This method now works for non-existent paths too. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 149284633 MOS_MIGRATED_REVID=149284633
* Convey the value of the --host_javabase startup option to the server.Gravatar Lukacs Berki2017-03-06
| | | | | | -- PiperOrigin-RevId: 149282686 MOS_MIGRATED_REVID=149282686
* Rollback of commit 14b53897b499da457e26aa779c3b63c85838f204.Gravatar Laszlo Csomor2017-03-03
| | | | | | | | | | | | | | *** Reason for rollback *** Fixed all errors. *** Original change description *** Automated [] rollback of commit 69a127b8f4e353ecb163688ed3271fb47e0f385d. -- PiperOrigin-RevId: 149092038 MOS_MIGRATED_REVID=149092038
* Bazel client: fix broken compilation Gravatar Laszlo Csomor2017-03-02
| | | | | | | | | | | | | | | | Do not include <windows.h> in file_platform.h because it #defines many symbols that later code, particularly function definitions, conflict with, e.g. GetUserName, SendMessage. This was breaking the Bazel bootstrap project on CI. -- Change-Id: Ie4b59b00fc617bd3e7d0cbb967c1232798e055de Reviewed-on: https://cr.bazel.build/9127 PiperOrigin-RevId: 148986922 MOS_MIGRATED_REVID=148986922
* Bazel client: do not use `errno`.Gravatar Laszlo Csomor2017-03-02
| | | | | | | | | | | | | | | Do not use `errno` in platform-independent code, because Windows API functions don't set it. This change abstracts away error handling and the functions whose `errno` result we care about, will set an input error variable. Fixes https://github.com/bazelbuild/bazel/issues/2506 -- PiperOrigin-RevId: 148977873 MOS_MIGRATED_REVID=148977873
* Bazel client: simplify {Read,Write}File semanticsGravatar Laszlo Csomor2017-03-01
| | | | | | | | | | | | | | | | 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
* Convert --use_action_cache to a regular optionGravatar Googler2017-03-01
| | | | | | | | RELNOTES: Convert --use_action_cache to a regular option -- PiperOrigin-RevId: 148804881 MOS_MIGRATED_REVID=148804881
* Bazel client: make some libraries visible to ijar Gravatar László Csomor2017-02-28
| | | | | | | | | | | | | | | | Ijar will use Bazel's file handling logic so that we don't have to maintain two implementations, and don't have to copy this code to implement the Windows/MSVC code path in third_party/ijar/platform_utils.cc. See https://github.com/bazelbuild/bazel/issues/2157 -- Change-Id: Iec327febb882aeaabae55216d0d06488f7c151ed Reviewed-on: https://cr.bazel.build/9068 PiperOrigin-RevId: 148770951 MOS_MIGRATED_REVID=148770951
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 16:51:42 +0000