aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* Fix Bazel crash on bad config_setting labels.Gravatar gregce2018-05-30
| | | | | | | | | | | | | | | | This used to work more smoothly. But the introduction of ConfiguredTargetAndData adds a Precondition check: https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetAndData.java;l=68?q=ConfiguredTargetAndData that crashes if innerConfigurationKey is null. The only way that can happen is when reading a bad label, which Bazel assumes (incorrectly in this case) to be a null-configured source file. Good times. PiperOrigin-RevId: 198557148
* Fix an incorrect example in the platform documentation.Gravatar jcater2018-05-30
| | | | PiperOrigin-RevId: 198556851
* Turn on pseudo locale generation for compilation.Gravatar corysmith2018-05-30
| | | | | RELNOTES: android_binary.aapt_version='aapt2' now supports en_XA and ar_XB PiperOrigin-RevId: 198555305
* Provide more details on the transition to Skylark {git,http}_repositoryGravatar Klaus Aehlig2018-05-30
| | | | | | | | In the description of incompatible changes, provide more information on the how to transition to the Skylark versions of the deprecated native rules. Change-Id: I30c6ee6560a4aed0d6d8356b00e6c1afec460f22 PiperOrigin-RevId: 198544104
* Fix `equals()` and `hashCode()` for artifacts: artifacts of different ↵Gravatar Dmitry Lomov2018-05-30
| | | | | | | | | | | | | classes are not equal. Also validate that there are no tree and file artifacts with the same exec path. Fixes #4668. Closes #5284. Change-Id: Id97c0407a476a5bfc697b4ca7b858e3d0c0f8c75 PiperOrigin-RevId: 198540425
* Allow passing the relative symlink resolution policy to the SpawnInputExpanderGravatar ulfjack2018-05-30
| | | | PiperOrigin-RevId: 198535546
* 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
* C++: Hide compilation context from SkylarkGravatar plf2018-05-30
| | | | | RELNOTES:none PiperOrigin-RevId: 198518792
* Rename r_txt from AndroidResourcesInfo to compiletime_r_txtGravatar asteinb2018-05-29
| | | | | | | | | | I didn't catch it at the time this field was initially introduced, but R files from Android libraries, exposed via AndroidResourcesInfo, are compiletime only. They should not be used at runtime or inherited from dependencies. Rename the field and add this warning to the description. RELNOTES: none PiperOrigin-RevId: 198448391
* Fix b/80260450 which saw cquery --output=proto crashing on alias configured ↵Gravatar juliexxia2018-05-29
| | | | | | | targets. Along the way, update ConfiguredTargetAccessor to return the correct Target (the alias, not the actual) when dealing with AliasedConfiguredTargets. RELNOTES: None. PiperOrigin-RevId: 198445580
* Expose Android data processing API in skylarkbuildapiGravatar asteinb2018-05-29
| | | | | | | | | | | | | | | | Expose the Android data processing API to skylarkbuildapi Rather than pass the SkylarkBuildApi interfaces (e.g., FileApi instead of Artifact) all the way through the Android data processing code, instead just cast them to the correct Bazel types. This is ugly, but is probably better than having to do multiple refactorings of the Android code. (A similar refactoring, for just a single type, took about 10 changes and 3300 lines of code.) The Skylark Build API is only meant for things exposed to Skylark, not Bazel internals, and, besides, when building with Bazel we should only expect inputs from other parts of Bazel. RELNOTES: none PiperOrigin-RevId: 198438519
* Propagate --experimental_prune_cpp_input_discovery to host builds. Otherwise,Gravatar Googler2018-05-29
| | | | | | | host builds don't profit from it. RELNOTES: None. PiperOrigin-RevId: 198437467
* 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
* Simplify RuleClass.Builder#cfg, Attribute.Builder#cfg interfaces.Gravatar gregce2018-05-29
| | | | PiperOrigin-RevId: 198427902
* Fix edge case in inferring Java package from path to targetsGravatar asteinb2018-05-29
| | | | | | | | When deriving the Java package from path to a target, actually derive it from the path to the entire target, not just the target's BUILD file. RELNOTES: none PiperOrigin-RevId: 198426047
* Merge ComposingSplitTransition and ComposingPatchTransition.Gravatar gregce2018-05-29
| | | | | | Part of https://docs.google.com/document/d/1_UJKmAQ9EE8i3Pl0il3YLTYr-Q9EKYYyLatt2zohfyM/edit# PiperOrigin-RevId: 198420365
* Use independently passed assets in aapt2 packaging as wellGravatar asteinb2018-05-29
| | | | | | | | | | | | | | Much earlier, I made a change that allowed passing assets without resources to aapt packaging. Do the same for aapt2 packaging too. The busybox seems to be expecting compiled symbols, so compile assets and pass the compiled version in. (Compiling assets doesn't save any time, but doesn't cost much either, and means that we'll eventually be able to phase out the parsed form entirely. Adapting the Busybox to take parsed assets would probably work too, but getting the code to handle it would be really messy.) RELNOTES: none PiperOrigin-RevId: 198417111
* Remove CcToolchainType rule.Gravatar jcater2018-05-29
| | | | PiperOrigin-RevId: 198413879
* Fixes Bazel build on Raspberry Pi 3 Raspbian GNU/Linux 9 (stetch). The ↵Gravatar Googler2018-05-29
| | | | | | | | | | | | | | | | | | portability bug is that sysconf() returns a long unsigned int but size_t is unsigned int (on the Pi 3) unsigned int causing a compilation failure (see below). Fixing the code to be portable, in this case, seems harmless in the common case where size_t is 64 bits AFAICT. (I don't know your org so please feel free to reassign.) The compilation error I received is: ERROR: /home/hallorant/src/bazel-0.13.1/third_party/ijar/BUILD:10:1: C++ compilation of rule '//third_party/ijar:zip' failed (Exit 1): gcc failed: error executing command (cd /tmp/bazel_TMQ6Ae45/out/execroot/io_bazel && \ exec env - \ PWD=/proc/self/cwd \ /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -B/usr/bin -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections -fdata-sections '-std=c++0x' -MD -MF bazel-out/host/bin/third_party/ijar/_objs/zip/third_party/ijar/mapped_file_unix.d '-frandom-seed=bazel-out/host/bin/third_party/ijar/_objs/zip/third_party/ijar/mapped_file_unix.o' -DBLAZE_OPENSOURCE -iquote . -iquote bazel-out/host/genfiles -iquote external/bazel_tools -iquote bazel-out/host/genfiles/external/bazel_tools -isystem third_party/zlib -isystem bazel-out/host/genfiles/third_party/zlib -isystem bazel-out/host/bin/third_party/zlib -g0 -g0 -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c third_party/ijar/mapped_file_unix.cc -o bazel-out/host/bin/third_party/ijar/_objs/zip/third_party/ijar/mapped_file_unix.o) third_party/ijar/mapped_file_unix.cc: In constructor 'devtools_ijar::MappedOutputFile::MappedOutputFile(const char*, size_t)': third_party/ijar/mapped_file_unix.cc:114:67: error: no matching function for call to 'min(long unsigned int, unsigned int)' std::numeric_limits<size_t>::max()); PiperOrigin-RevId: 198405201
* 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
* Properly expose asset provider for targets without explicit manifestGravatar asteinb2018-05-29
| | | | | RELNOTES: none PiperOrigin-RevId: 198402335
* 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
* Make ConstantRuleVisibility static constants into @AutoCodec constants.Gravatar janakr2018-05-29
| | | | PiperOrigin-RevId: 198398386
* Move Android data info classes to skylarkbuildapiGravatar asteinb2018-05-29
| | | | | | | | | | Expose all Android data info classes as interfaces in skylarkbuildapi. Most methods are not exposed in the interface since they are not exposed in Skylark. In fact, stop exposing a few methods from AndroidResourcesInfo that are exposed but shouldn't be. RELNOTES: none PiperOrigin-RevId: 198396677
* 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 pretty-printer class to SkylarkGravatar Klaus Aehlig2018-05-29
| | | | | | | | | | | With the recording of the results of repository rules (that eventually will lead to an implementation of the WORKSPACE.resolved proposal) bazel started writing out lengthy Skylark values. To make this file more readable for humans, add a Skylkark printer that does at least some basic line breaking and indenting. Change-Id: I469d029421df9212b43747509dd17bd6c64da4a8 PiperOrigin-RevId: 198389112
* Avoid unnecessary work in validating C++ inclusions. Specifically:Gravatar Googler2018-05-29
| | | | | | | | | | | | | | - declaredIncludeSrcs don't need to be looked at as they also become part of the compilation prerequisites (see CcCompilationContext.addDeclaredIncludeSrc()) - transitiveModules can never be "incorrect" as they get computed and added by Bazel itself. - declaredIncludeDirs/warnIncludeDirs can be computed lazily. As most people aim for a warning-free build, it is rarely necessary to compute either set in practice. RELNOTES: None. PiperOrigin-RevId: 198386262
* Refactor root cause reporting in ConfiguredTargetFunctionGravatar ulfjack2018-05-29
| | | | | | We now track Causes instead of plain Labels, which will allow us to do better reporting in the future. Add basic tests. PiperOrigin-RevId: 198380468
* docs, website: remove bad `sh` from commandGravatar Laszlo Csomor2018-05-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The MarkDown engine we use for the Bazel website renders the following MarkDown block: foo: ```sh bar ``` to HTML as: foo: <code>sh bar</code> when in fact it should render it as: foo: <code class="sh">bar</code> This resulted in a bad command that the users couldn't run as it was on the website. Change-Id: If127ca83375b4d1f8c6403fdec16bbd79498cb5d Closes #5288. Change-Id: If127ca83375b4d1f8c6403fdec16bbd79498cb5d PiperOrigin-RevId: 198380352
* Remove a reference to an unused field in the CROSSTOOL proto.Gravatar lberki2018-05-29
| | | | | RELNOTES: None. PiperOrigin-RevId: 198378682
* Add compilerFlagForMigrationDoNotUse field to cc_commonGravatar rosica2018-05-29
| | | | | | | This will help migration from config_setting.values{"compiler"} to config_setting.flag_values{"@bazel_tools//tools/cpp:compiler"} RELNOTES: None. PiperOrigin-RevId: 198377299
* Add CcSysrootAliasRuleGravatar dbabkin2018-05-29
| | | | | RELNOTES:none PiperOrigin-RevId: 198364550
* Remove CppCompileAction.optionalSourceFileGravatar hlopko2018-05-28
| | | | | | | It's unused. RELNOTES: NONE. PiperOrigin-RevId: 198316668
* Treat runfiles middlemen as aggregating middlemen.Gravatar Benjamin Peterson2018-05-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to, for an action execution, make only a single skyframe edge to every required runfiles tree rather than an edge to every runfiles artifact directly. We accomplish this by pulling the runfiles artifacts' metadata for a particular runfiles tree through the appropriate runfiles middlemen artifact in one batch. This CL fixes https://github.com/bazelbuild/bazel/issues/3217. This change makes runfiles middlemen more similar to aggregating middlemen. We however continue to treat runfiles middlemen slightly differently than true aggregating middlemen. Namely, we do not expand runfiles middlemen into the final action inputs. The reasons for this are: 1. It can make latent bugs like https://github.com/bazelbuild/bazel/issues/4033 more severe. 2. The runfiles tree builder action's output MANIFEST contains absolute paths, which interferes with remote execution if its metadata is added to a cache hash. 3. In the sandbox, it causes the runfiles artifacts to be mounted at their exec path locations in addition to within the runfiles trees. This makes the sandbox less strict. (Perhaps tolerably?) 4. It saves a modicum of (transient) memory and time to not expand. If the first two issues are fixed, it could be a nice simplification to completely replace runfiles middlemen with aggregating middlemen. Change-Id: I2d2148297f897af4c4c6dc055d87f8a6fad0061e PiperOrigin-RevId: 198307109
* Add flags to help enforce that android_local_test does not depend directly ↵Gravatar tomlu2018-05-28
| | | | | | | on a proto_library. RELNOTES: None PiperOrigin-RevId: 198304295
* Clean up Java proto_library attributes.Gravatar tomlu2018-05-28
| | | | | RELNOTES: None PiperOrigin-RevId: 198304282
* Windows: Make environment variables case-insensitive when creating Windows ↵Gravatar Yun Peng2018-05-28
| | | | | | | | | | | | process If users pass the same environment variables with different cases, the last one will override the previous ones. Fixed https://github.com/bazelbuild/bazel/issues/5285 Change-Id: Ieec857553bc54a4ad9809455687551303037e240 PiperOrigin-RevId: 198303684
* Don't create a HashSet/Map just to copy them into the Immutable-counterpartGravatar Googler2018-05-28
| | | | | | | later. This wastes CPU cycles (directly and during GC). RELNOTES: None. PiperOrigin-RevId: 198302706
* Remove the unused TestRunnerAction.useTestRunner attribute.Gravatar lberki2018-05-28
| | | | | RELNOTES: None. PiperOrigin-RevId: 198302692
* Do not cache RepositoryResolvedEventsGravatar Klaus Aehlig2018-05-28
| | | | | | | | | | When recording the resolved state of rules, restrict to rules actually executed during the respective invocation. Cached return values can be confusing in a log that is about knowning what a fresh refetch would result in. Change-Id: I39688bf73e4e33fa1c6b0e00c52817c0ade3c0a4 PiperOrigin-RevId: 198301021
* Add an option --experimental_prune_cpp_input_discovery to stop C++ inputGravatar Googler2018-05-28
| | | | | | | | discovery at the boundary of modular headers. C++ modules generally should be self-contained and a using a C++ module doesn't require any of it's transitive source files to be present. PiperOrigin-RevId: 198299936
* CommandHelper: do not look up shell's pathGravatar Laszlo Csomor2018-05-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CommandHelper no longer looks up the shell interpreter's path itself. Instead its ctor takes the path as an argument. This change will allow incrementally migrating rules that use CommandHelper to start depending on the shell toolchain. Shell-using rules today only use the ShellConfiguration config fragment to look up the shell's path. In the future, more and more rules will also retrieve the active shell toolchain, and be able to: 1. use the auto-detected local shell interpreter's location, especially when it's not the default /bin/bash 2. use 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: I4da4e77e7d1fe57e8e4f5eb8820d03a840915e20 Closes #5283. Change-Id: I4da4e77e7d1fe57e8e4f5eb8820d03a840915e20 PiperOrigin-RevId: 198298315
* Fix typo in cpp.mdGravatar ????2018-05-28
| | | | | | | | | Hi, I fixed a typo in the tree representation of tutorial directories/files at `cpp.md`. Closes #5276. PiperOrigin-RevId: 198297573
* Add a compiler_flag rule that exposes the value of the "compiler" field of ↵Gravatar rosica2018-05-28
| | | | | | | CROSSTOOL RELNOTES: None PiperOrigin-RevId: 198295290
* Add a missing dependency from checker framework dataflow to javacutilsGravatar Liam Miller-Cushon2018-05-28
| | | | | | Fixes #5134, #1008 Change-Id: Ic34e26b17b2ebee75f36e9f56f8e5c2ec6205bc0
* Enable --experimental_remote_spawn_cache by defaultGravatar ulfjack2018-05-28
| | | | | | | | | | | | | | | | | | | | | - It is now an error to specify the gRPC remote execution backend in combination with a local disk or HTTP-based cache. - It is now an error to specify both local disk and HTTP-based caches. Note that before this CL, enabling the local disk cache silently disabled remote execution - we now give an error in that case. With these combination no longer being accepted, remote execution being enabled now means that we only create a RemoteSpawnRunner, and don't provide a SpawnCache. This is not a semantic change - we never created both. In principle, it should be possible for users to combine local execution with remote caching for actions that are marked local or no-remote, and still use remote execution otherwise. However, Bazel cannot currently express this combination of execution strategies. RELNOTES: The --experimental_remote_spawn_cache flag is now enabled by default, and remote caching no longer needs --*_strategy=remote flags (it will fail if they are specified). PiperOrigin-RevId: 198280398
* Skylark: Exposes disabled features from rule context to SkylarkGravatar plf2018-05-28
| | | | | | WANT_LGTM=all RELNOTES:none PiperOrigin-RevId: 198269370
* Fix jdeps handling in java_common.compile(exports)Gravatar cushon2018-05-27
| | | | PiperOrigin-RevId: 198262096
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-09 04:28:40 +0000