| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
| |
ctor. This is completely wasteful in the common case of the PathFragment already being normalized.
RELNOTES: None
PiperOrigin-RevId: 164022960
|
|
|
|
| |
PiperOrigin-RevId: 164013246
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 163979668
|
|
|
|
|
|
|
|
|
| |
Also throw IllegalArgumentException instead of AssertionError.
A follow-up CL will look to eliminate the SkylarkMutable#checkMutable(Location, Environment) override in favor of checkMutable(Location, Mutability). This will make it easier to manipulate Skylark values in specialized contexts aside from normal evaluation.
RELNOTES: None
PiperOrigin-RevId: 163978262
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
(https://user-images.githubusercontent.com/744228/28495342-609be784-6efe-11e7-8403-0f3c5e892b13.png)
Closes #3436.
PiperOrigin-RevId: 163968685
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 163966473
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 163942164
|
|
|
|
| |
PiperOrigin-RevId: 163889699
|
|
|
|
|
|
|
| |
PrepareDepsOfPatternsValue#TargetPatternSequence
RELNOTES: None
PiperOrigin-RevId: 163883014
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
In the TestSummary, also indicate the total number of cached actions.
Fixes #3435.
Change-Id: I5fb3f54f54a852b7cbeb58b03b50b042e5d26455
PiperOrigin-RevId: 163871517
|
|
|
|
|
|
|
|
|
| |
If a test fails to build, we obviously cannot run it.
Therefore, it does not make sense to have a summary of
the individual test runs.
Change-Id: I0445e7a58fc5c1f4feaa592a13da1c7f9c9be083
PiperOrigin-RevId: 163866309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
| |
|
|
|
|
|
|
|
| |
I.e., use an accessor for type inference. The EMPTY field will be made private in a future CL.
RELNOTES: None
PiperOrigin-RevId: 163843569
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 163838735
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for setting up the LTO indexing step when the inputs
contain bitcode.
Added a python BuildViewTestCase that provokes this, as well as a
ThinLTO GoogleBuildIntegrationTestCase to the existing NativeDeps
testing.
PiperOrigin-RevId: 163827441
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows CROSSTOOL authors to add flags to all targets for which fission
is enabled, even when a compile action does not output split debug info.
For example, when building with ThinLTO, compiles are split into a frontend
compile, that does not generate split debug info, but still needs to include
debug info if fission is enabled (even in opt mode).
RELNOTES: None.
PiperOrigin-RevId: 163825563
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add flag --convert_lipo_to_thinlto, which allows builds with LLVM to use
ThinLTO when the user specifies LIPO + FDO flags; if that flag is not set, and
the user requests a build with LLVM, the compile will now fail.
Add an attribute supports_lipo to the DefaultCpuToolchain crosstool proto and
skip default toolchains that do not support LIPO when the user has specified
LIPO flags in the toolchain selection; this enables CROSSTOOL files to cause
an implicit fallback to a hybrid / LIPO toolchain when using an LLVM toolchain
as the default.
Add a CrosstoolBuilder to MockCcSupport and add a new method
setupCrosstoolFromScratch that allows unit tests to fully control the setup.
The other methods available in MockCcSupport will always load in a default
CROSSTOOL file and may show different unit test results depending on the
content of that file.
RELNOTES: None.
PiperOrigin-RevId: 163819246
|
|
|
|
|
|
|
| |
Also added basic tests.
Change-Id: I5861816bf116486e0ee365debd3dfbda131047f7
PiperOrigin-RevId: 163764257
|
|
|
|
|
|
|
|
|
| |
context.
Fixes #3428.
Change-Id: Ib3f45bc6856651cfb29d338d0b4480ba1dd77cea
PiperOrigin-RevId: 163760940
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks some iOS Photos targets: []
*** Original change description ***
Framework dependency subtraction uses runfiles path instead of full artifact path
RELNOTES: None.
PiperOrigin-RevId: 163732608
|
|
|
|
|
|
|
|
|
|
| |
I noticed that one of the exceptions that causes #2470 is
SocketTimeoutException. The outer exception handlers of
HttpConnector.connect have logic to handle such an exception, so just
let them propagate.
Change-Id: Ic87b678431178e296f14f1be34acf8024ddbfc19
PiperOrigin-RevId: 163732268
|
|
|
|
|
|
|
|
| |
Follows
https://docs.google.com/document/d/1aAIVWvHPERDz2cv_PCFGwr8dvh5FcAkENFoRsNS4clk/.
RELNOTES: None.
PiperOrigin-RevId: 163728291
|
|
|
|
|
|
|
| |
We now use a unified way to check provider requirements everywhere.
RELNOTES: None.
PiperOrigin-RevId: 163710961
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163703995
|
|
|
|
| |
PiperOrigin-RevId: 163701792
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a data-dependency on the windows_jni.dll from
the BusyBox in BUILD.tools, so the BusyBox in
@build_tools// can actually find it at runtime.
Also update the script that builds the .dll so
that it works if the source files have an
"external/bazel_tools/" prefix.
Related to https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I005e9d2c00253a59d2cd5cc9f3a93528dc4d2e9e
PiperOrigin-RevId: 163691320
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise these envvars are not available to the
Java program and it can't load its runfiles.
I tested that this is necessary both on Linux and
Windows.
Related to https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I2bd8eee0793b26aeedeafc6900f7854c816b5b14
PiperOrigin-RevId: 163688341
|
|
|
|
|
|
|
|
|
| |
'is_executable'.
This is for consistency with 'ctx.actions.write'.
RELNOTES: None.
PiperOrigin-RevId: 163687973
|
|
|
|
|
|
|
|
| |
Fix https://github.com/bazelbuild/bazel/issues/3474
Fix https://github.com/bazelbuild/bazel/issues/3472
RELNOTES: None
PiperOrigin-RevId: 163677371
|
|
|
|
|
|
|
|
|
|
| |
The only way to use those was in the `ctx.action(...executable...)`
parameter, made that accept string.
Fixes #2931.
RELNOTES: None.
PiperOrigin-RevId: 163511248
|
|
|
|
|
|
|
| |
path
RELNOTES: None.
PiperOrigin-RevId: 163484010
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 163471182
|
|
|
|
|
|
|
|
|
| |
DeclaredToolchainInfo.
Fixes #3458.
Change-Id: I24dd6d9d24432b9aaf0229de658f07e465ad63cb
PiperOrigin-RevId: 163466882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Actually hook up the resource filtering configuration transitions to
AndroidConfiguration's topLevelConfigurationHook.
Dynamic configuration is inefficient when multiple configurations are used.
Multiple configurations result in splitting the build graph and duplicating
work.
To avoid using multiple configurations as much as possible, dynamically
configured resource filtering will only be applied for top-level android_binary
targets. When android_binary targets are included as dependencies, it's very
likely that multiple binaries with many shared dependencies but different
configurations would be used. Only applying dynamic filtering to top-level
binaries removes this concern.
It is still possible to build multiple top-level binary targets with different
configurations at once. Previous versions of this code considered not using
dynamic configuration in that case as well, but that raised some unanswered
questions about whether Bazel's invariants should allow modifying one target's
configuration based solely on targets that happen to be building in parallel.
As a result, that optimization is not included for now; we assume that
developers manually building multiple similar binaries at once is relatively
rare (plus, dynamically configured resource filtering in general is not turned
on by default and will not be turned on by default until we're confident the
benefits outweigh the costs).
RELNOTES: none
PiperOrigin-RevId: 163464415
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than assuming that all events are part of a build until
NoBuildEvent or BuildCompleteEvent are posted, only start reporting
build progress after a BuildStartingEvent or a NoBuildEvent with
showProgress() true happens.
This fixes https://github.com/bazelbuild/bazel/issues/3449.
Change-Id: I78372a2286a4595cf3301c998be2c9036ad0f4b7
PiperOrigin-RevId: 163447622
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change:
1. Added launcher to @bazel_tools
If the host platform is Windows, we use a prebuilt launcher.exe
, otherwise the launcher needs to be built with MSVC first.
2. Launching sh_binary using native launcher.
Change-Id: I5a63135455057fbfe04ff0cce7ec7994ef0c347a
PiperOrigin-RevId: 163442540
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163436254
|
|
|
|
|
|
|
|
|
|
|
| |
transitive dependencies, in the list of transitive jars that a java_xxx_proto_library rule exposes.
This fixes b/63723368, in a way that no action is required.
The new behavior is guarded by a flag.
RELNOTES: None
PiperOrigin-RevId: 163421788
|
|
|
|
|
|
|
| |
Also fix the remaining violations.
RELNOTES: None.
PiperOrigin-RevId: 163391215
|
|
|
|
|
|
|
|
|
|
| |
1) Update the javadocs.
2) Clarify that allowedRuleClases and allowedRuleClassesWithWarning
must be disjoint sets.
3) Enforce 2).
4) Fix error messaging when only "with warnings" is set.
PiperOrigin-RevId: 163379567
|
|
|
|
|
|
|
| |
Instead use MetadataHandler.getMetadata().isFile(), which is basically what
isRegularFile did before.
PiperOrigin-RevId: 163351014
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163343931
|
|
|
|
|
|
| |
Fixes a bug where the flags would be ignored during Bazel's compile.sh bootstrap.
PiperOrigin-RevId: 163341779
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163338873
|
|
|
|
|
|
|
|
|
|
| |
If a remote download fails, delete any output files that might have
already been created. Else, this might intefere with a subsequent
locally executed actions that expects none of its output files to
exist. See #3452.
Change-Id: I467a97d05606c586aa257326213940a37dad9dd5
PiperOrigin-RevId: 163336093
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163331254
|
|
|
|
|
|
|
|
|
|
|
|
| |
From one of the boost gurus:
If you want to split up your template sources into interface and implementation
(there are lots of good reasons to do that, including controlling
instantiation), you can't very well use the same name (foo.hpp) twice, and
foo.cpp wouldn't be appropriate for either one. foo.ipp clearly delineates the
file as an implementation file intended to be #included in foo.hpp.
RELNOTES: None.
PiperOrigin-RevId: 163329612
|