aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/cpp
Commit message (Collapse)AuthorAge
* blaze_util::ConvertPath should not make paths absolute.Gravatar ccalvarin2018-06-07
| | | | | | | | | 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
* Move path-manipulation functions to own library file.Gravatar ccalvarin2018-06-05
| | | | | | | | | | | 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
* Set no_proxy=localhost when an http_proxy is detected, instead of deleting ↵Gravatar ruperts2018-06-04
| | | | | | | | | 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
* Add --ignore_all_rc_files startup options.Gravatar ccalvarin2018-05-15
| | | | | | | | | | | | | 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
* Windows, Java launcher: Support jar files under different drivesGravatar Yun Peng2018-05-14
| | | | | | | | | 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
* Use the local JDK as the default target javabaseGravatar cushon2018-05-14
| | | | | | and continue to use the embedded JDK as the default host_javabase. PiperOrigin-RevId: 196471714
* c++,runfiles: move runfiles libraryGravatar Laszlo Csomor2018-04-30
| | | | | | | | | | | | | | | | 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
* Automated rollback of commit 52356e76a02067e9dc79b469e9b97bd017d077ab.Gravatar jingwen2018-04-27
| | | | | | | | | | | *** 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
* Automatic code cleanup.Gravatar Googler2018-04-27
| | | | PiperOrigin-RevId: 194602500
* windows,client: no longer support Unix-style pathsGravatar Laszlo Csomor2018-04-26
| | | | | | | | | | | | | | 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
* windows,client: fix error reportingGravatar Laszlo Csomor2018-04-24
| | | | | | | | | | | | | | | | | | | | | | 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
* Declare internal helper functions in option_processor-internal.Gravatar ccalvarin2018-04-23
| | | | | | | 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
* Remove overlap between the blazerc and bazelrc names.Gravatar ccalvarin2018-04-20
| | | | | | | | 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
* Reduce the state kept in OptionProcessor.Gravatar jmmv2018-04-19
| | | | | | | | | | | | | | | 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
* Refactor where rc files are controlled.Gravatar ccalvarin2018-04-19
| | | | | | | 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
* windows: change output_base name computationGravatar Laszlo Csomor2018-04-19
| | | | | | | | | | | | | | | | | 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
* Keep LANG/LANGUAGE and related environment variables for the process spawned ↵Gravatar lberki2018-04-18
| | | | | | | by "blaze run --direct_run". RELNOTES: None. PiperOrigin-RevId: 193391379
* windows: GetOutputRoot() returns GetHomeDir()Gravatar Laszlo Csomor2018-04-18
| | | | | | | | | | | | 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
* Bring startup_options to BAZEL_LOG.Gravatar ccalvarin2018-04-10
| | | | | RELNOTES: None. PiperOrigin-RevId: 192313667
* Delete unused RunProgram function.Gravatar Benjamin Peterson2018-04-10
| | | | | | | Closes #4986. Change-Id: I81bbec801116ec1f45416bba7a724d7f00b9b00c PiperOrigin-RevId: 192253687
* Made 'file_posix.cc' POSIX compatibleGravatar Jasper Siepkes2018-04-09
| | | | | | | | | | | | | | | | 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
* Remove die() and replace it with BAZEL_DIE, part of the logging framework.Gravatar ccalvarin2018-04-06
| | | | | | | This will mean the messages will make it to the right output stream. RELNOTES: PiperOrigin-RevId: 191925662
* Create BAZEL_DIE macro.Gravatar ccalvarin2018-04-03
| | | | | | | Will migrate die() instances in a later change, to keep this one clean. RELNOTES: None. PiperOrigin-RevId: 191491701
* Make the client's java startup command line list all startup options.Gravatar ccalvarin2018-03-30
| | | | | | | | | | | 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
* Remove pdie.Gravatar ccalvarin2018-03-29
| | | | | | | 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
* Remove startup JVM version checkGravatar cushon2018-03-29
| | | | | | | | | | | | 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
* Remove the --allow_configurable_attributes startup option.Gravatar ccalvarin2018-03-27
| | | | | | | It was removed from the java code 4 years ago, mentioning it causes the server to crash at startup. RELNOTES: None. PiperOrigin-RevId: 190636455
* Fold in warning and error output into client logging.Gravatar ccalvarin2018-03-23
| | | | | | | To replace blaze_util::die and blaze_util::pdie as well, FATAL statements need to accept blaze exit codes. RELNOTES: None. PiperOrigin-RevId: 190285798
* Update the client's skeleton logging framework to use it for --client_debug.Gravatar ccalvarin2018-03-21
| | | | | | | | | 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
* blaze.cc: Remove unused had_to_wait variableGravatar David Ostrovsky2018-03-21
| | | | | | Closes #4851. PiperOrigin-RevId: 189897065
* Automated rollback of commit 8a5a0a3ed1e19768b6ee024189307bb4ac27460d.Gravatar laszlocsomor2018-03-21
| | | | | | | | | | | | | | | | | | | | | | | | | *** 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
* runfiles,C++: move to //tools/cpp/runfilesGravatar Laszlo Csomor2018-03-21
| | | | | | | | | | | | | | | | | | 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
* Automated rollback of commit c2b332b45e6ea41a14ecbd3c5f30782bcdeec301.Gravatar laszlocsomor2018-03-14
| | | | | | | | | | | | | | | | | | | *** 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
* Prefix startup dots with "Connecting to local Bazel server..." message.Gravatar ruperts2018-03-12
| | | | | RELNOTES: None. PiperOrigin-RevId: 188744724
* Add unit tests for rc parsing.Gravatar ccalvarin2018-03-08
| | | | | | | | | | | | | | | | | 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
* Convert static std::set to constexpr arrayGravatar Loo Rong Jie2018-03-01
| | | | | | | | | | | | | 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
* runfiles,C++: implement manifest-based runfilesGravatar Laszlo Csomor2018-02-28
| | | | | | | | | | | | | | | | 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
* Expose --output_user_base to the Bazel server processGravatar Klaus Aehlig2018-02-27
| | | | | | | | | | | ...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
* Use std::to_string for non-mingw/cygwinGravatar Loo Rong Jie2018-02-27
| | | | | | | | | | `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
* Flip --expand_configs_in_place to true by default in Bazel.Gravatar ccalvarin2018-02-23
| | | | | | | 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
* windows: replace custom JunctionResolverGravatar Laszlo Csomor2018-02-22
| | | | | | | | | | | | 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
* Bazel client: remove dead codeGravatar Laszlo Csomor2018-02-20
| | | | | | | | | Remove the static kAsciiPropertyBits data from strings.cc and replace its only reference with simpler code. Change-Id: I95fb12b7d4bca4589ae64603b63019ee6e12bfc2 PiperOrigin-RevId: 186295165
* [MSVC] Detect 64-bit with _WIN64Gravatar Loo Rong Jie2018-02-14
| | | | | | | Fixes MSVC C4311 pointer truncation warning. Change-Id: Ic64168d620db010717189200c37c419cccac0653 PiperOrigin-RevId: 185653953
* [Windows] Use %ls to print wstringGravatar Loo Rong Jie2018-02-13
| | | | | Change-Id: Icbc478f87d622665b16c13c76518087ac089899e PiperOrigin-RevId: 185645880
* Automatic ClangTidyReadability code cleanup.Gravatar Googler2018-02-13
| | | | PiperOrigin-RevId: 185528799
* [MSVC] Don't declare environ when it is already defined as macroGravatar Loo Rong Jie2018-02-12
| | | | | | | | | | | | | | | | 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
* Combine WorkspaceRcFileSearchPath and FindCandidateBlazercPaths and add a test.Gravatar ajmichael2018-02-07
| | | | | RELNOTES: None PiperOrigin-RevId: 184865343
* Refactor blazerc parsing out of OptionProcessor. This change should be a ↵Gravatar Googler2018-02-07
| | | | | | | no-op behavior-wise. RELNOTES: None PiperOrigin-RevId: 184843442
* Add a "direct" mode to "blaze run" that makes the process being run a directGravatar lberki2018-02-05
| | | | | | | | | | | | | | 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
* Use the workspace name in the process title of the Bazel server.Gravatar philwo2018-02-01
| | | | | | | | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-03 16:25:41 +0000