| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
This is a prequisite to removing cc_toolchain_type entirely.
PiperOrigin-RevId: 198402472
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 198402335
|
|
|
|
|
|
| |
Closes #5044.
PiperOrigin-RevId: 198399012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 198398386
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198378682
|
|
|
|
|
|
|
| |
This will help migration from config_setting.values{"compiler"} to config_setting.flag_values{"@bazel_tools//tools/cpp:compiler"}
RELNOTES: None.
PiperOrigin-RevId: 198377299
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 198364550
|
|
|
|
|
|
|
| |
It's unused.
RELNOTES: NONE.
PiperOrigin-RevId: 198316668
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
on a proto_library.
RELNOTES: None
PiperOrigin-RevId: 198304295
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 198304282
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
later. This wastes CPU cycles (directly and during GC).
RELNOTES: None.
PiperOrigin-RevId: 198302706
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198302692
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Hi,
I fixed a typo in the tree representation of tutorial directories/files at `cpp.md`.
Closes #5276.
PiperOrigin-RevId: 198297573
|
|
|
|
|
|
|
| |
CROSSTOOL
RELNOTES: None
PiperOrigin-RevId: 198295290
|
|
|
|
|
|
| |
Fixes #5134, #1008
Change-Id: Ic34e26b17b2ebee75f36e9f56f8e5c2ec6205bc0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
| |
WANT_LGTM=all
RELNOTES:none
PiperOrigin-RevId: 198269370
|
|
|
|
| |
PiperOrigin-RevId: 198262096
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198126134
|
|
|
|
| |
PiperOrigin-RevId: 198124705
|
|
|
|
|
|
| |
Fixes #5260
PiperOrigin-RevId: 198110476
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198107604
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198103940
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198095817
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198094324
|
|
|
|
|
|
|
| |
This is no longer meaningful with the turndown of
(C++) LIPO.
PiperOrigin-RevId: 198092974
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198086078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a precursor to removing the DATA transition outright.
While we could also have changed the Mode.DATA instances to
Mode.TARGET (which would declare that we expect the attribute not
to apply any transition), that would break existing definitions and
make depot cleanup more delicate. Plus, these checks weren't being
consistently applied across attributes anyway so they don't really
offer much. A lot of this logic is really just leftover legacy
from the pre-dynamic configuration days.
PiperOrigin-RevId: 198085059
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Roll forward after fixing and rolling forward culprit CL. No changes besides rolling forward (masked by diffbase)
RELNOTES: none
PiperOrigin-RevId: 198084160
|
|
|
|
| |
PiperOrigin-RevId: 198081030
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Roll forward with fix:
I was assuming that R.txt and symbols files are always set, but they can be
null in some cases (especially in the old data processing pipeline). Properly
handle them here.
RELNOTES: none
PiperOrigin-RevId: 198075743
|
|
|
|
| |
PiperOrigin-RevId: 198074986
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 198071932
|
|
|
|
|
|
|
|
|
|
| |
This is a rollforward of CL/197725926 after depot fix.
NEW: Additional deletions of unused providers (no constructor call references).
NEW[last rollforward]: Allow java_* rules to depend on proto_libraries via runtime_deps and exports. This should avoid the breakage that caused the original rollback. The edges are no-ops and could be removed.
PiperOrigin-RevId: 198060345
|
|
|
|
|
|
|
|
| |
This is part of a chain of CLs that will pull initialization of
CcCompilationContext from CcCompilationHelper.
RELNOTES:none
PiperOrigin-RevId: 198060027
|
|
|
|
|
|
|
|
| |
Fixes #5263
RELNOTES: execution strategies line no longer handles differently the case
where all processes have the same strategy.
PiperOrigin-RevId: 198057496
|
|
|
|
| |
PiperOrigin-RevId: 198053509
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Crashes lots of targets in nightly blaze-2018.05.24-1:
PiperOrigin-RevId: 198049395
|