aboutsummaryrefslogtreecommitdiffhomepage
path: root/tools
Commit message (Collapse)AuthorAge
...
* CROSSTOOLS wrapped_clang: handle spaces in pathsGravatar Oscar Bonilla2018-06-12
| | | | | | | | | | | | | | | | When bazel calls wrapped_clang, it single-quotes all arguments. However it passes flags with arguments quoted as a whole. That is, wrapped_clang will be called with arguments like these: wrapped_clang '-isysroot /a/path/with spaces' '/a/file with spaces.m' Before this commit, wrapped_clang was blindly splitting on space and calling clang with invalid arguments. Now it only splits on the _first_ space, and only if the argument starts with '-'. Closes #5147. PiperOrigin-RevId: 200259496
* Fix some missing cases from ↵Gravatar Googler2018-06-12
| | | | | | | | | | | | | | | | https://github.com/bazelbuild/bazel/commit/bbf3e421ed8b2b431a72cd3ab4ba591dc8833634. For languages that use launchers, there are some requirements about files other than the main executable being co-located with the executable: 1. For Python, the .zip file must be alongside the executable. 2. For Shell, the shell file must be alongside the exe. In addition, a .exe suffix is needed for launchers. Tested that cc_test (non-launcher), java_test, py_test, sh_test (all launchers) work remotely when using the TEST_SHORT_EXEC_PATH env var. RELNOTES: N/A PiperOrigin-RevId: 200216308
* Implement LcovMerger.Gravatar elenairina2018-06-11
| | | | | | | | | | | | | | LcovMerger is a tool that merges all the intermediate lcov tracefiles (with .dat extension) found under a coverage directory and prints the merged tracefile to a given output file. A custom implementation for merging lcov tracefiles is needed because the merging functionality of lcov itself is very slow. LcovMerger is required to get a single coverage report (lcov tracefile) from a bazel coverage command that executes multiple tests. ATM LcovMerger is only invoked by tools/test/collect_coverage.sh that collects and merges the tracefiles from a single test invocation. It will also be used from a CoverageReportAction. Progress on #5246. PiperOrigin-RevId: 200054506
* Add the ability to force the path to the test binary to a fixed length by ↵Gravatar Googler2018-06-11
| | | | | | | | | | | using a symlink. This is enabled with --test_env=TEST_SHORT_EXEC_PATH=true. Passing CI run: https://buildkite.com/bazel/google-bazel-presubmit/builds/3576 RELNOTES: N/A PiperOrigin-RevId: 200050318
* Remove usage of COMPILER_MSVC in Bazel and ijarGravatar Loo Rong Jie2018-06-11
| | | | | | | | | | | | | 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
* Automated rollback of commit 5df8eb24f84a6943e70876c805c77f06e719dcd7.Gravatar Googler2018-06-08
| | | | PiperOrigin-RevId: 199864175
* Add support for aar_import_external and aar_maven_import_externalGravatar Jingwen Chen2018-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usage example: ```python # In WORKSPACE load("@bazel_tools//tools/build_defs/repo:android.bzl", "aar_import_external", "aar_maven_import_external") # Specify the URL directly: aar_import_external( name = "com_android_support_preference_v14_25_1_0", # required licenses = ["notice"], # required aar_urls = [ # required "https://dl.google.com/dl/android/maven2/com/android/support/preference-v14/25.1.0/preference-v14-25.1.0.aar" ], aar_sha256 = "442473fe5c395ebef26c14eb01d17ceda33ad207a4cc23a32a2ad95b87edfabb", # optional or empty string deps = [ # optional or empty list "@com_android_support_recyclerview_v7_25_1_0//aar", "@com_android_support_appcompat_v7_25_1_0//aar", "@com_android_support_preference_v7_25_1_0//aar", "@com_android_support_support_v4_25_1_0//aar", ], ) # Or, specify the artifact coordinate: aar_maven_import_external( name = "com_android_support_preference_v14_25_1_0", # required artifact = "com.android.support.test:preference-v14:25.1.0", # required sha256 = "442473fe5c395ebef26c14eb01d17ceda33ad207a4cc23a32a2ad95b87edfabb" # optional or empty string licenses = ["notice"], # required server_urls = ["https://maven.google.com"], # required deps = [ # optional or empty list "@com_android_support_recyclerview_v7_25_1_0//aar", "@com_android_support_appcompat_v7_25_1_0//aar", "@com_android_support_preference_v7_25_1_0//aar", "@com_android_support_support_v4_25_1_0//aar", ], ) # In BUILD.bazel android_library( name = "foo", srcs = [...], deps = [ "@com_android_support_preference_v14_25_1_0//aar", ], ) ``` To test this out with gmaven_rules, change the `load` statement in https://github.com/bazelbuild/gmaven_rules/blob/master/gmaven.bzl to ``` load('@bazel_tools//tools/build_defs/repo:android.bzl', 'aar_import_external') load('@bazel_tools//tools/build_defs/repo:java.bzl', 'java_import_external') ``` Fixes https://github.com/bazelbuild/bazel/issues/4654 RELNOTES: New rules for importing Android dependencies: `aar_import_external` and `aar_maven_import_external`. `aar_import_external` enables specifying external AAR dependencies using a list of HTTP URLs for the artifact. `aar_maven_import_external` enables specifying external AAR dependencies using the artifact coordinate and a list of server URLs. Closes #5319. Change-Id: I9517e68ab78f2e30fb6ceabfe3b35061c585d607 PiperOrigin-RevId: 199839047
* Automated rollback of commit ccaccb2b277a82f7264567563a02ab133a0f6e6f.Gravatar jmmv2018-06-07
| | | | | | | | | | | | | | | *** Reason for rollback *** Suspected root cause behind tons of Blaze nightly failures. One example: [] *** Original change description *** Let blaze obfuscate manual main_dex_list according to proguard map. PiperOrigin-RevId: 199737371
* Expose C++ action names to SkylarkGravatar hlopko2018-06-07
| | | | | | | | | | | | | | This cl adds Skylark constants allowing users to specify which C++ action they want for the feature configuration Skylark API. This is done by exposing a Skylark file at @bazel_tools//tools/cpp:action_names.bzl. Skylark api to the C++ toolchain doc: https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit#. Progress on #4571. RELNOTES: None. PiperOrigin-RevId: 199596778
* Let blaze obfuscate manual main_dex_list according to proguard map.Gravatar Googler2018-06-06
| | | | PiperOrigin-RevId: 199529974
* 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
* Don't rely on shell splitting; explicitly make these multiple argumentsGravatar ulfjack2018-06-05
| | | | | | One step towards #5147. PiperOrigin-RevId: 199281558
* Use BUILD.bazel instead of BUILD for external projectsGravatar Dmitry Petrashko2018-06-05
| | | | | | | | | | While upgrading an internal project from 0.10 to 0.13 we have found that we no longer were able to build one of external non-basel dependencies that already has a lowercase `build` directory in their repo. As the name `BUILD` is much more common than `BUILD.bazel`, in particular on file systems that are case-insensitive, I propose to generate the latter by default. Closes #5146. PiperOrigin-RevId: 199264025
* Make tools in action inputs an error.Gravatar tomlu2018-06-02
| | | | | | | | | | Supporting tools in inputs introduces a slow linear scan. Such tools should be moved to the 'tools' attribute. If --incompatible_no_support_tools_in_action_inputs is set the inputs are scanned, but a helpful error message is issued to the user. Eventually we will remove the slow scanning. Errors will surface in the execution phase instead of during analysis, and the resulting error messages will be less obvious. RELNOTES: None RELNOTES[INC]: With --incompatible_no_support_tools_in_action_inputs enabled, Skylark action inputs are no longer scanned for tools. Move any such inputs to the newly introduced 'tools' attribute. PiperOrigin-RevId: 198996093
* Fix broken flag existence check for linking flags in unix_cc_configure.Gravatar hlopko2018-06-01
| | | | | | | Fixes #5090 RELNOTES: NONE. PiperOrigin-RevId: 198870918
* Format all bzl files with buildifierGravatar vladmos2018-06-01
| | | | | | This CL aslo enables a presubmit check for correct formatting of all bzl files in //third_party/bazel. PiperOrigin-RevId: 198857055
* Update tools/cpp/toolchain_utils.bzl to return the proper C++ toolchainGravatar hlopko2018-05-30
| | | | | RELNOTES: None PiperOrigin-RevId: 198676014
* runfiles,cc: C++ runfiles library in @bazel_toolsGravatar Laszlo Csomor2018-05-30
| | | | | | | | | | | | | | Add the C++ runfiles library to @bazel_tools//tools/cpp/runfiles:runfiles. RELNOTES[NEW]: C++,runfiles: to access data-dependencies (runfiles) in C++ programs, use the runfiles library built into Bazel. For usage info, see https://github.com/bazelbuild/bazel/blob/master/tools/cpp/runfiles/runfiles.h Change-Id: I5057a9f477289eea7244c60105e77fc71652a817 Closes #5293. Change-Id: I90cba6fa4c6595c838ae42f9d2c17548c8387e5d PiperOrigin-RevId: 198531849
* Automated rollback of commit 7fcbc8ffdead028d19606fefa2fa3be13781da98.Gravatar laszlocsomor2018-05-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** According to a post-submit regression test, this commit increased Bazel's memory usage slightly beyond some threshold. That event prompted me to consider and question the necessity of this commit. My goal is to make Bazel work on Windows without requiring MSYS, failing the build only if an action is a shell action. Toolchainifying the shell is related to, but not required by this effort. What is required is to fail the build when Bazel tries to create a shell action but the shell is missing, and we have that already with ShToolchain.getPath (which only considers the ShellConfiguration fragment). What's missing for my goal is to reimplement hardcoded shell actions (i.e. SpawnAction.builder().setShellCommand(...)) without using the shell where possible. *** Original change description *** shell toolchain: genrule now uses it genrule() now uses the shell toolchain (as well as the ShellConfiguration config fragment) to look up the shell interpreter's path. Also the CommandHelper no longer looks up the shell interpreter's path itself. Instead its ctor takes the path as an argument. This allows supporting rules that already use the shell toolchain and rules that still only consider the configuration fragment. With these changes genrule() is now able to use the shell interpreter registered as a toolchain, even if there's no `--shell_executable` flag specified (or its value is empty). Subsequent commits will migrate more and more rules to depend on the shell toolchain. This commit takes us closer to: 1. be able to detect the local shell interpreter's location, especially when it's not the default /bin/bash 2. be able to define different shell toolchains (different interpreter paths) for remote builds 3. gracefully fail the build if the machine has no shell installed but the action graph included a shell action See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7 Closes #5282. *** RELNOTES: none PiperOrigin-RevId: 198527351
* Minimize the cost of Skyframe restarts during CC autoconfiguration.Gravatar jmmv2018-05-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Repository functions restart whenever they have to resolve a label due to the way Skyframe currently works. This is problematic because such functions are often costly: they try to detect features of the host system by building and running tools, and they touch the file system. To minimize the cost of these restarts, which are unavoidable, resolve the paths to all necessary labels upfront. This way, while the restarts still happen, they have no side-effects and thus are cheap. As a side-effect of this work, remove the strange and undocumented "tpl" function, which only made things more cryptic and harder to refactor. This cuts down Bazel's own analysis time on macOS on my Mac Pro 2013 from 14 seconds to 6 seconds by trimming about 15 unnecessary rebuilds and executions of the xcode-locator-bin tool to just 1. In other words: one fewer awkward pause during analysis time. Additionally, there is the hope that this will fix the problems users observe where Bazel writes persistent garbage during autoconfiguration (needing "clean --expunge" to recover) when Visual Studio Code is running and Santa is enabled on macOS; see https://github.com/bazelbuild/bazel/issues/4603. This is most likely a bug in Santa (see https://github.com/google/santa/issues/260) but we were tickling it due to our apparently-abusive behavior of building, executing, and then removing the same thing over and over again. Fixes https://github.com/bazelbuild/bazel/issues/5196 and should also fix https://github.com/bazelbuild/bazel/issues/4603. RELNOTES: None. PiperOrigin-RevId: 198434395
* Change uses of cc_toolchain_type back to plain toolchain_type.Gravatar jcater2018-05-29
| | | | | | This is a prequisite to removing cc_toolchain_type entirely. PiperOrigin-RevId: 198402472
* Add ability to add runfiles to tarGravatar Christian Verkerk2018-05-29
| | | | | | Closes #5044. PiperOrigin-RevId: 198399012
* Generaliaze java_import_external to jvm_import_externalGravatar natans2018-05-29
| | | | | | | | | | | | | | | | | | | | | This PR copies "upstream" a change made to java_import_external in`rules_scala` (see [PR](https://github.com/bazelbuild/rules_scala/pull/473)) This change was originally proposed by @dslomov [here](https://github.com/bazelbuild/bazel/issues/3528) (search for 'jvm_import_external') java_import_external was changed to `jvm_import_external` 'template like' rule + `java_import_external` macro in order to allow for other jvm languages (e.g. scala and kotlin) to utilize the 'import_external' functionality without copying the boiler plate again and again. This has already been used in `rules_scala` with the introduction of `scala_import_external` and `scala_maven_import_external` In addition to the `import rule name`, `jvm_import_external` can also be called with custom attributes needed by the underlying import rules, as well as a custom load statement. `java_import_external` is used as a macro in rules_scala to make sure it's still functioning properly after the change. `jvm_maven_import_external` exposes maven artifact terminology. This will also allow to create a `maven_import_external` macro that will delegate to `jvm_maven_import_external` with a `maven_import` rule which will have `MavenCoordinates` Provider as discussed [here](https://github.com/bazelbuild/bazel/issues/4654) Closes #5068. PiperOrigin-RevId: 198398621
* shell toolchain: genrule now uses itGravatar Laszlo Csomor2018-05-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | genrule() now uses the shell toolchain (as well as the ShellConfiguration config fragment) to look up the shell interpreter's path. Also the CommandHelper no longer looks up the shell interpreter's path itself. Instead its ctor takes the path as an argument. This allows supporting rules that already use the shell toolchain and rules that still only consider the configuration fragment. With these changes genrule() is now able to use the shell interpreter registered as a toolchain, even if there's no `--shell_executable` flag specified (or its value is empty). Subsequent commits will migrate more and more rules to depend on the shell toolchain. This commit takes us closer to: 1. be able to detect the local shell interpreter's location, especially when it's not the default /bin/bash 2. be able to define different shell toolchains (different interpreter paths) for remote builds 3. gracefully fail the build if the machine has no shell installed but the action graph included a shell action See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7 Closes #5282. Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7 PiperOrigin-RevId: 198394021
* Add a compiler_flag rule that exposes the value of the "compiler" field of ↵Gravatar rosica2018-05-28
| | | | | | | CROSSTOOL RELNOTES: None PiperOrigin-RevId: 198295290
* Use pipes.quote() rather than manual quoting, and do so consistently ↵Gravatar diamondm2018-05-24
| | | | | | | wherever shell=True is set. RELNOTES: None PiperOrigin-RevId: 197939143
* shallow_since tests and doc improvementsGravatar Ed Baunton2018-05-24
| | | | | | | | | | | | This changeset introduces tests for the `shallow_since` functionality that was introduced in 6496b1d1d25025f33406b1eaf9949cab126f08bd. We test that if the user specifies a tag as well as a `shallow_since` that it fails since they are incompatible. We also verify that specifying a commit before the `shallow_since` date causes the clone to fail (albeit currently with a non-useful error message; perhaps that could be improved at a later date). It also documents more clearly how to use the feature by explaining the format of the 'since' string. Closes #5183. PiperOrigin-RevId: 197875727
* runfiles,cc: merge strategies into RunfilesGravatar Laszlo Csomor2018-05-24
| | | | | | | | | | | | | | Merge the manifest- and directory-based runfiles strategies into the Runfiles class. The resulting Runfiles object can look up runfiles from the manifest or from the filesystem, as needed. Change-Id: Ifff4b76849ce67248bb9152901024e241aaea800 Closes #5251. Change-Id: Ifff4b76849ce67248bb9152901024e241aaea800 PiperOrigin-RevId: 197863872
* git.bzl: fall back to full clone if shallow options are not supportedGravatar Klaus Aehlig2018-05-24
| | | | | | | | | | The `--shallow-since` option of git was introduced only in version 2.11 of git. However, some widely used distributions ship older versions of git. So fall back to fully cloning or fetching a repository if the respective shallow option is not know to the ambient git command used. Change-Id: I8f0aa0a12e294ff9cc8325975bd9333f6bf50939 PiperOrigin-RevId: 197863797
* runfiles,cc: Runfiles uses manifest AND directoryGravatar Laszlo Csomor2018-05-23
| | | | | | | | | | | | | | | | | | | | | | | | Change the C++ runfiles library so it can use the runfiles manifest (if present) and the runfiles directory (if present) simultaneously. If the Runfiles object fails to look up a runfile from the manifest (or the manifest didn't exist or wasn't found) then it looks it up from the runfiles directory. This change allows using the same binary with and without a runfiles tree, which is often what sets local and remote runs apart. https://github.com/bazelbuild/bazel/issues/4460 Change-Id: Iae879ff084ba084fcd7c111638ddeae4c6754f4f Closes #5235. Change-Id: Iae879ff084ba084fcd7c111638ddeae4c6754f4f PiperOrigin-RevId: 197726412
* http.bzl: add http_jarGravatar Klaus Aehlig2018-05-23
| | | | | | | | http_jar is another version of the native http_archive. So add it to the Skylark-implementation as well. Change-Id: Icbaafe18d4836e14b0f5eb09dc3ab0607f9e391d PiperOrigin-RevId: 197719717
* CROSSTOOL: Make C++ compiled and linked artifact name pattern configurableGravatar Yun Peng2018-05-22
| | | | | | | | | | | | This change makes Bazel respect artifact name patterns specified in CROSSTOOL. Users cannot specify any arbitrary name pattern, it must ends with allowed extensions. For example, for dynamic library, it can only ends with .so, .dylib or .dll, otherwise Bazel throws an error. Change-Id: I21d9e6fa7c3a282e1a9b8ff29679b00925cddb33 PiperOrigin-RevId: 197553413
* runfiles,python: add a method to discover runfilesGravatar Laszlo Csomor2018-05-22
| | | | | | | | | | | | | | | | | | | | The new method discovers the runfiles manifest and runfiles directory using the values of the RUNFILES_MANIFEST_FILE and RUNFILES_DIR envvars (if specified), and if needed, also looks for them next to sys.argv[0]. This commit is a copy of https://github.com/bazelbuild/bazel/commit/9f2b052d93bfd188687f28fe6771f390d3626936 ported from C++ to Python. See https://github.com/bazelbuild/bazel/issues/4460 Change-Id: I6916366ca73575703fe39ce69020eec3b54457bf Closes #5233. Change-Id: I6916366ca73575703fe39ce69020eec3b54457bf PiperOrigin-RevId: 197544480
* cpp runfiles library: precompute envvars mapGravatar Laszlo Csomor2018-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compute the list of environment variables when creating the runfiles library instead of computing it on-demand. Since we already have the manifest and directory path from Runfiles::PathsFrom, creating the vector is cheap, though we have to store it even if we don't use it later. In a subsequent change I'll merge the manifest- and directory-based implementations into RunfilesImpl, and collapse RunfilesImpl into the Runfiles base class. The point of that is to make the runfiles library be able to handle both the directory-based and the manifest-based case simultaneously, dependening on what is available to it in the filesystem. See https://github.com/bazelbuild/bazel/issues/4460 Change-Id: I56310423528df2d0f7494f45904150193368e2d6 Closes #5218. Change-Id: I73d1f44611c4b0a73c41162319d0ba7a8a4ae6d7 PiperOrigin-RevId: 197543865
* cpp runfiles library: compute manifest/dir pathsGravatar Laszlo Csomor2018-05-18
| | | | | | | | | | | | | | | | | | | Use the new codepath (Runfiles::PathsFrom) to compute the paths of the runfiles manifest file and runfiles directory. This method considers the RUNFILES_* envvars but also the argv0 value, and tries hard to discover where the runfiles manifest or directory is. See https://github.com/bazelbuild/bazel/issues/4460 Change-Id: I041b9d12f5c4138853fac1c2bf48873af8e2bd93 Closes #5216. Change-Id: I041b9d12f5c4138853fac1c2bf48873af8e2bd93 PiperOrigin-RevId: 197146764
* Portability with BSD stat in collect_coverage.shGravatar Siddhartha Bagaria2018-05-17
| | | | | | | | BSD stat does not have --printf option. Closes #5162. PiperOrigin-RevId: 196965302
* Split user_link_flags from legacy_link_flagsGravatar hlopko2018-05-16
| | | | | | | | The difference between them is that user_link_flags will stay after we remove legacy fields from the crosstool. RELNOTES: None. PiperOrigin-RevId: 196940832
* Replace use of output_object_file with output_file in CROSSTOOLS.Gravatar hlopko2018-05-16
| | | | | RELNOTES: None. PiperOrigin-RevId: 196870840
* Enable proguarded Android builds with --experimental_desugar_java8_libs in BazelGravatar kmb2018-05-16
| | | | | | RELNOTES: Bazel supports including select Java 8 APIs into Android apps targeting pre-Nougat Android devices with --experimental_desugar_java8_libs PiperOrigin-RevId: 196833987
* Remove unneeded exec_compatible_with from local_sh_toolchainGravatar Klaus Aehlig2018-05-16
| | | | | | | | | | Since that restriction is not necessary at the moment, we can as well not compute it in the first place. Potentially to be cherry-picked for 0.14.0, see #5056. Change-Id: Ic2d4ec1b037ce464e85e243b69bedd483bc515ac PiperOrigin-RevId: 196819791
* Rewrite lcov path munging to make the paths all relativeGravatar Ulf Adams2018-05-16
| | | | | | | | | | | | | This makes coverage work with sandboxing, and gets rid of a previous workaround. The only downside is that it requires running genhtml in the exec root in order to be able to resolve relative pahts to source files, like so: (GENHTML_CMD="genhtml -o $(pwd)/report/ -p "$(readlink -f bazel-project)" $(readlink -f bazel-testlogs)/path/to/coverage.dat" && cd bazel-project && $GENHTML_CMD) Closes #5043. PiperOrigin-RevId: 196814568
* http_archive: Support workspace_file and workspace_file_contentsGravatar Klaus Aehlig2018-05-16
| | | | | | | ...to be fully compatible with the native rules. Change-Id: Ie340f73ec530ef0c8f50215a331f28f523398db8 PiperOrigin-RevId: 196801227
* Do not autodetect C++ toolchain when BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1 is ↵Gravatar hlopko2018-05-16
| | | | | | | | | | | | present This is useful e.g. when all C++ builds happen remotely and there's no C++ toolchain installed on the host machine. Fixes #5133. RELNOTES: None. PiperOrigin-RevId: 196798471
* Replace --experimental_android_enforce_strict_deps_for_binaries_under_test ↵Gravatar cushon2018-05-15
| | | | | | with a package whitelist PiperOrigin-RevId: 196688645
* sh_configure.bzl: FreeBSD is also a known platformGravatar Klaus Aehlig2018-05-15
| | | | | Change-Id: I51ffe838d8c0e067f8e5ab3a6aef18e1ad063638 PiperOrigin-RevId: 196666303
* http.bzl: drop outdated commentGravatar Klaus Aehlig2018-05-15
| | | | | | | | Since cdc99afc1a03ff8fbbbae088d358b7c029e0d232 label arguments are prefetched. So it is no longer necessary to access them early. Change-Id: I6d30bae3ac655387641ffd98f9b9aa95d2f1ece7 PiperOrigin-RevId: 196632853
* Don't default to --release 9 when running on a JDK 9 host_javabaseGravatar cushon2018-05-14
| | | | PiperOrigin-RevId: 196518906
* 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
* Allow conditional keep rules in proguard_whitelister.Gravatar Googler2018-05-07
| | | | PiperOrigin-RevId: 195757274
* Explicitly assign --buildroot in the rpmbuild invocationGravatar mmikitka2018-05-03
| | | | | | | | | | | | | | | Occasionally, I see the following error messages when running a pkg_rpm target: ` INFO: Analysed target //foo/deploy:pkgs (1 packages loaded). INFO: Found 1 target... INFO: From Executing genrule //foo/deploy:pkgs: error: cannot open Packages database in /home/mmikitka/.rpmdb ` This PR explicitly sets the --buildroot to address this error message. Closes #5102. PiperOrigin-RevId: 195254300
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-07 09:11:03 +0000