| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
These are depended upon by analysis code, so need to live in the same library
as lib.analysis. Moving them here makes it possible to split the build-base
library into separate libraries for analysis, execution, and rules.
PiperOrigin-RevId: 164847161
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164835678
|
|
|
|
|
|
|
| |
crosstool
RELNOTES: None.
PiperOrigin-RevId: 164830825
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
RELNOTES: None
PiperOrigin-RevId: 164775289
|
|
|
|
|
|
|
| |
to get googletest.sh from to put in the runfiles.
RELNOTES: None
PiperOrigin-RevId: 164737919
|
|
|
|
|
|
|
| |
Memory is saved by sharing the format string and label object instances, instead of constructing new strings for each action.
RELNOTES: None
PiperOrigin-RevId: 164731899
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having custom ArgvFragments for every combination of desired things, we make a combined "interpreter" of argvs. This saves memory and simplifies things as we do not have to allocate a strategy instance per call to args (instead pushing a single shared instance, followed by the args).
The generic interpreter does have a lot of branching compared to the bespoke implementations, but because the branch is always the same for long stretches the branch predictor should easily be able to handle it with minimal overhead (~1 cycle per branch IIRC).
This CL also elevates that we either want a NestedSet or an ImmutableCollection to the surface of the API, so consumers understand the cost when they call it with a non-immutable collection. Most of the changes in clients is due to this.
To cut down on CL churn, @Deprecated forwarding methods are added to CustomCommandLine. These will be removed in a separate CL using IDE inlining.
RELNOTES: None
PiperOrigin-RevId: 164725370
|
|
|
|
|
|
| |
in blaze. This should be enabled only after the blaze release, otherwise it makes code coverage drop, mainly due to including auto-generated files in the coverage report.
PiperOrigin-RevId: 164724689
|
|
|
|
|
|
| |
Relevant document: https://docs.google.com/document/d/1d4SPgVX-OTCiEK_l24DNWiFlT14XS5ZxD7XhttFbvrI/edit
PiperOrigin-RevId: 164715084
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164701931
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 164701570
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Updated to avoid https://github.com/bazelbuild/bazel/issues/3501
This is a rollback of a rollback, with additional
modifications to BazelConfiguration.java to fix
https://github.com/bazelbuild/bazel/issues/3501,
the issue that was the reason we rolled back the
original change.
The additional updates serve to propagate the
client's TMP and TEMP envvars to the action, which
is a short-term solution to allow actions have a
TMP/TEMP envvar on Windows. They need at least one
of those to create temp directories.
The long-term solution is to set a value for TMP
or TEMP in the executor just before executing the
actions, so the TMP/TEMP would not be part of the
action key.
All of this only affects Bazel on Windows.
*** Original change description ***
Automated rollback of commit 0abf5fa2d64c76def5a8fa0f960b73ce0566af4d.
*** Reason for rollback ***
Breaks Bazel CI (https://github.com/bazelbuild/bazel/issues/3501)
*** Original change description ***
Android BusyBox: actions use the default shell env
SpawnActions that run the Android BusyBox now use
the default shell environment.
This has the following benefits:
- Bazel propagates the PATH, TMPDIR envvars to the
action
- Bazel propagates the --action_env envvars to the
action
This allows the Bazel client to pass
--action_env=TMP or --action_env=TEMP (whichever
of the envvars is defined) to the server, so the
BusyBox actions will have TMP/TEMP set (to the
same value as the clientenv), so they can create
temp directories using
java.nio.file.Files.createTempDirectory.
This method seems to be calling the GetTempPath
WinAPI function, which needs the TMP or TEMP
envvar, otherwise it falls back to returning
c:\windows which is non-writable.
There's one drawback of using the default shell
environment, although @ulfjack is working on it:
- PATH is now also part of the action's cache key.
However in a single-machine environment (no
remote execution) and assuming PATH isn't likely
to change between builds, this probably doesn't
poision the action cache in practice.
This change is a short-term solution. Propagating
the client env's TMP/TEMP means we make that part
of the action's cache key.
The ideal long-term solution will be to not
propagate this envvar, and instead let the
execution strategy set it to some
client-env-independent value.
See https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I756a4203b5d86c881bc36cc089e35cde0d419914
RELNOTES: none
PiperOrigin-RevId: 164696600
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 164646858
|
|
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules. Unfortunately, there are a number of reverse deps
from analysis code to Skylark classes, so moving these is the only way to make
progress.
PiperOrigin-RevId: 164612957
|
|
|
|
| |
PiperOrigin-RevId: 164590595
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, Bazel will always use params files for
some BusyBox tools, because some flags of these
tools expect values with special characters in
them.
We need this change so Bazel can safely pass such
flags to the BusyBox on Windows.
See https://github.com/bazelbuild/bazel/issues/3264
RELNOTES: none
PiperOrigin-RevId: 164582899
|
|
|
|
| |
PiperOrigin-RevId: 164581142
|
|
|
|
| |
PiperOrigin-RevId: 164577062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change is needed due to the fact that java_import or other custom rules (genrules or Skylark) do not propagate coverage information. The lack of coverage data is caused by the fact that it is retrieved from compilation information and it is passed around through providers as Artifact(s) (also known as instrumentation metadata). The problem with the current implementation is that there is no way of retrieving instrumentation metadata from arbitrary jars provided by java_import or other custom rules.
The instrumentation metadata in the current implementation is a separate jar that contains uninstrumented classes for offline Jacoco instrumentation.
This change addresses that problem by having just one jar instead of 2 (the build jar and the instrumentation jar), adding the uninstrumented classes in the build jar and completely removing any other instrumentation metadata.
Implementation details:
* For each build jar there is a .txt file created that contains the relative path of each Java file. This file will also be included in the final build jar. It is used for recreating the correct path for each covered file when included in the coverage report.
* java_binary/java_test will set 2 environment variables:
1) JACOCO_METADATA_JARS - replaces the previous JACOCO_METADATA_JAR that was a jar that merged all the uninstrumented classes on the classpath in one jar. The new environment variable holds the paths of the runtime classpath jars - only some of them contain uninstrumented classes, letting the Jacoco coverage runner to filter and analyze them.
2) JACOCO_MAIN_CLASS - The main class to be called for the current coverage run. Previously this information was embedded in the JACOCO_METADATA_JAR's manifest.
PiperOrigin-RevId: 164562533
|
|
|
|
|
|
|
| |
of full artifact path"
RELNOTES: None.
PiperOrigin-RevId: 164496520
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164456961
|
|
|
|
|
|
|
|
|
| |
Change https://github.com/bazelbuild/bazel/commit/63dabb6cfd55febc14e221ec51b18120558bc23c refactored the coverage feature, but wrongly started
add coverage flags when the gcno file was not expected/read by bazel. This
can be harmful, since the size of inputs increases unnecessarily.
RELNOTES: None.
PiperOrigin-RevId: 164455431
|
|
|
|
|
|
|
|
| |
All spawn strategies must expand artifacts, so actions shouldn't
themselves.
Change-Id: I051f7a6fee31330893271fbec7b93197bd4292f3
PiperOrigin-RevId: 164449128
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164446955
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries
for analysis, exec, and rules.
PiperOrigin-RevId: 164438390
|
|
|
|
|
|
|
| |
J2ObjcAspect ignores them.
RELNOTES: None
PiperOrigin-RevId: 164335492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Roll-forward.
unknown commit fixed the internal protoc to also accept full paths, just as the external one does. Fixes #2265
*** Original change description ***
Automated rollback of commit bcd23553f38f54fd4846aa507c827a4ee40cfab4.
*** Reason for rollback ***
RELNOTES: None
PiperOrigin-RevId: 164324424
|
|
|
|
|
|
| |
--test_env isn't moved in this CL since it's exposed to Skylark via BuildConfiguration, making it a somewhat riskier refactor.
PiperOrigin-RevId: 164266168
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change https://github.com/bazelbuild/bazel/commit/646cfd81793fc3b87979089aab873310d14e95e6 moved copts to the build variable and in order to keep the
ordering of the flags as before the copts feature needs to be the last feature
in the toolchain. Osx crosstool generator sometimes appended additional
features, that broke this assumption. This cl makes sure copts is the last
feature. In addition, flags directly from action_config will be added first, not
last as they were before.
RELNOTES: Flags from action_config get added first to the command line first,
before the flags from features.
PiperOrigin-RevId: 164257469
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deprecate the --libraries flag of the
GENERATE_BINARY_R tool in favour of --library.
The new flag is multi-value and uses "," as the
pair-separator instead of ":".
The value converter still supports ":"-separated
pairs as well, but looks for "," first.
Old format:
--libraries=key1:value1,key2:value2,...
New format:
--library=key1,value1 --library=key2,value2
Motivation:
- the ":"-separator prevents using absolute paths
on Windows
The old flag is still supported, but will be
removed after 2018-02-28 (about 6 months from
now).
Also in this commit:
- add a new method to CustomCommandLine.Builder
to lazily construct the command line for the
--library flag
See https://github.com/bazelbuild/bazel/issues/3264
RELNOTES: none
PiperOrigin-RevId: 164246506
|
|
|
|
|
|
|
|
|
|
|
|
| |
If no_stripping feature is enabled, then strip action config is not
necessary, building stripped binary will just copy the orignial binary.
Fix https://github.com/bazelbuild/bazel/issues/3482
Also fixed CI breakage:
https://github.com/bazelbuild/bazel/issues/3505
Change-Id: Ie78fe174c42248c9b3e930008eef96dcd1864741
PiperOrigin-RevId: 164237588
|
|
|
|
|
|
|
|
|
| |
Add SpawnAction.Builder#setProgressMessageNonLazy for dynamic strings. This should help guide users to the right method.
This also helped find a few methods I'd missed previously that could use a constant-string version.
RELNOTES: None
PiperOrigin-RevId: 164150264
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Bazel CI (https://github.com/bazelbuild/bazel/issues/3501)
*** Original change description ***
Android BusyBox: actions use the default shell env
SpawnActions that run the Android BusyBox now use
the default shell environment.
This has the following benefits:
- Bazel propagates the PATH, TMPDIR envvars to the
action
- Bazel propagates the --action_env envvars to the
action
This allows the Bazel client to pass
--action_env=TMP or --action_env=TEMP (whichever
of the envvars is defined) to the server, so the
BusyBox actions will have TMP/TEMP set...
***
PiperOrigin-RevId: 164126020
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think this code predates being able to load Skylark .bzl files
from the WORKSPACE. As most non-trivial projects are using load()
in the WORKSPACE, it's fairly uninformative to say "it was
defined in the WORKSPACE file" for this error.
This is to help debug the Tensorflow issue (#3478) but should
generally be more useful than the current message.
PiperOrigin-RevId: 164118176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SpawnActions that run the Android BusyBox now use
the default shell environment.
This has the following benefits:
- Bazel propagates the PATH, TMPDIR envvars to the
action
- Bazel propagates the --action_env envvars to the
action
This allows the Bazel client to pass
--action_env=TMP or --action_env=TEMP (whichever
of the envvars is defined) to the server, so the
BusyBox actions will have TMP/TEMP set (to the
same value as the clientenv), so they can create
temp directories using
java.nio.file.Files.createTempDirectory.
This method seems to be calling the GetTempPath
WinAPI function, which needs the TMP or TEMP
envvar, otherwise it falls back to returning
c:\windows which is non-writable.
There's one drawback of using the default shell
environment, although @ulfjack is working on it:
- PATH is now also part of the action's cache key.
However in a single-machine environment (no
remote execution) and assuming PATH isn't likely
to change between builds, this probably doesn't
poision the action cache in practice.
This change is a short-term solution. Propagating
the client env's TMP/TEMP means we make that part
of the action's cache key.
The ideal long-term solution will be to not
propagate this envvar, and instead let the
execution strategy set it to some
client-env-independent value.
See https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I756a4203b5d86c881bc36cc089e35cde0d419914
PiperOrigin-RevId: 164114502
|
|
|
|
|
|
| |
Fixes #3434
PiperOrigin-RevId: 164113116
|
|
|
|
|
|
|
|
|
|
| |
This cl introduces new action_config named 'strip' for the strip action. While
at it, it fixes support for executionRequirements.
Fixed #209
RELNOTES: 'strip' action is now configured via feature configuration
PiperOrigin-RevId: 164110478
|
|
|
|
|
|
|
|
|
|
| |
Consumers using spawn action builder now have access to handy overloads that behind the scene do a lazy String.format. In 95% of cases progress messages are expressible as 0, 1, or 2 argument String.formats.
This saves memory because the format string is constant and shared between all actions, and the captured subjects are usually live on the heap anyway (eg. labels).
Skylark still computes its progress messages eagerly. If we want similar savings there I'd have to follow up with a Skylark proposal.
PiperOrigin-RevId: 164068816
|
|
|
|
|
|
| |
The other test configuration options will follow in subsequent CLs to keep size manageable.
PiperOrigin-RevId: 164068510
|
|
|
|
| |
PiperOrigin-RevId: 164066205
|
|
|
|
|
|
|
|
|
| |
We now use a unified way to check provider requirements everywhere.
Reland of https://github.com/bazelbuild/bazel/commit/c32e1b1efcd703b3780de47fba62974123593d71.
RELNOTES: None.
PiperOrigin-RevId: 164038621
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 164031163
|
|
|
|
| |
PiperOrigin-RevId: 164013246
|
|
|
|
|
|
| |
As suggested in readability review for https://github.com/bazelbuild/bazel/commit/2789c97149a1f253b659aa0f2401f44705a3258f. Ended up being a fair number of changes, but I think I got them all.
PiperOrigin-RevId: 163975846
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 163942164
|
|
|
|
| |
PiperOrigin-RevId: 163889699
|
|
|
|
|
|
|
|
|
|
|
| |
This cl changes copts to be immutable (and changes addCopts methods into
setCopts, so it's simpler to reason about copts) and exposes copts as a build
variable. It also introduces CompileBuildVariablesTest, similar to
LinkBuildVariablesTest, to test that right build variables are exposed for right
actions.
RELNOTES: None.
PiperOrigin-RevId: 163876774
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks depot b/64250728
*** Original change description ***
Use RequiredProviders to validate rule prerequisites in RuleContext.
We now use a unified way to check provider requirements everywhere.
RELNOTES: None.
PiperOrigin-RevId: 163862067
|
| |
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 163838735
|