| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 183677348
|
|
|
|
| |
PiperOrigin-RevId: 183668291
|
|
|
|
|
|
|
|
|
|
| |
Allow symbolic links in zip archives, as long as they refer to
a file within the same archive.
Fixes #2656.
Change-Id: I0b21b8bb79a7e999ef191baa2a71d29745ac65e4
PiperOrigin-RevId: 183664725
|
|
|
|
| |
PiperOrigin-RevId: 183662908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add logging to bazel_bootstrap_distfile_test in
case it is running on Windows. The logging will
help collect basic performance stats.
Also remove the %N placeholder from `date` format
string in the log messages, because macOS doesn't
support it.
See https://github.com/bazelbuild/bazel/issues/4503
Change-Id: Idf00bf1512d02a793b27e1cc761fbcd630e79618
PiperOrigin-RevId: 183642578
|
|
|
|
|
|
|
|
|
| |
Do this by exposing DeviceBrokerInfo and a constructor for it in android_common.
See AndroidInstrumentationTestTest for an example.
RELNOTES: None
PiperOrigin-RevId: 183432674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* This puts in the foundation of HTTP/2 support for remote caching.
* Allows us to remove the Apache HTTP library as a dependency, reducing
the Bazel binary size by 1MiB.
On fast networks (i.e. GCE to GCS) we can see a >2x speed improvement for TLS
throughput. Even from my workstation to GCS I get significant build time
improvements when using Netty's TLS 18s vs 12s.
Closes #4481.
PiperOrigin-RevId: 183411787
|
|
|
|
|
|
|
| |
It is optional as of https://github.com/bazelbuild/bazel/commit/1a6ca6f47aef36d56b5cb2f9da114af75dde583d.
RELNOTES: None
PiperOrigin-RevId: 183391869
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 183388075
|
|
|
|
|
|
|
|
|
|
|
| |
do the same with the target one.
I'm not exactly happy at this development, but we already have a host of --host_* options so it's only incremental badness.
Fixes #4484.
RELNOTES: None.
PiperOrigin-RevId: 183375817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...as completion of the respective top-level targets. In this way,
a failure is associated to its root cause, even if the cause is at
analysis phase; in particular, visibility errors are correctly
associated.
For the time beeing, we associate visibility root causes only with
labels; it is planned to change that to the more accurate configured
labels in a follow-up change.
Change-Id: I04121a7cd2099fc65171eae0719fd77b98aef09b
PiperOrigin-RevId: 183359798
|
|
|
|
|
|
|
| |
Fixes #2138.
Change-Id: I176f59a9c3bdde5052681547acb455a47871761c
PiperOrigin-RevId: 183354994
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds some logging to test helpers for size of serialized data.
Jan 25, 2018 7:16:25 AM com.google.devtools.build.lib.skyframe.serialization.testutils.SerializerTester testSerializeDeserialize
INFO: total serialized bytes = 70
Jan 25, 2018 7:16:25 AM com.google.devtools.build.lib.skyframe.serialization.testutils.ObjectCodecTester testSerializeDeserialize
INFO: total serialized bytes = 208
Kryo output is significantly smaller.
PiperOrigin-RevId: 183300353
|
|
|
|
|
|
| |
in the host config instead of the usual hash of options.
PiperOrigin-RevId: 183293164
|
|
|
|
|
|
|
|
| |
This interface makes it clearer in the type system exactly how items that go into a CustomCommandLine are turned into strings.
It is a preparatory change to allow command line fingerprints to be more cheaply calculated, but it is valuable in itself from a code quality standpoint.
PiperOrigin-RevId: 183274022
|
|
|
|
|
|
|
|
| |
...works as expected, caching only based on the predicted sha256 sum and
also is available for bazel query. Closes #2780.
Change-Id: I64f09728d9def561a6ac3960f8fa36540aba31dc
PiperOrigin-RevId: 183257435
|
|
|
|
|
|
| |
of the final steps of the migration process into Skylark. If you were using ios_test, please take a look at ios_unit_test provided by the github.com/bazelbuild/rules_apple project.
PiperOrigin-RevId: 183251623
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 183246711
|
|
|
|
|
|
|
| |
I've attempted to recreate the flakiness, to see if changing the test from a wait-based approach to actual locking would improve the flakiness, but the test seems to not have flaked since it was broken out into its own target, so it seems that might just add unnecessary complexity.
RELNOTES: None.
PiperOrigin-RevId: 183235405
|
|
|
|
|
|
|
|
| |
TestConfigFragment.
Thanks to shahan@ for the TestConfigFragment code.
PiperOrigin-RevId: 183127152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Made obsolete by https://github.com/bazelbuild/bazel/commit/e734c479956df7a675c61f531d769609d3af3e5d
*** Original change description ***
Blaze now passes an extra flag to JavaBuilder, --testonly, to
mark compilations of test code.
We plan to use this for Error Prone checks that need to distinguish
between test and production code, such as enforcing
@VisibleForTesting.
PiperOrigin-RevId: 183121768
|
|
|
|
|
|
| |
start-lib/end-lib should not be passed to ar. Fix how the libraries to link are passed to ar by not using the generic feature "libraries_to_link"
PiperOrigin-RevId: 183107904
|
|
|
|
|
|
|
|
| |
BuildConfiguration.Fragment>> set of Fragment classes that is part of the BuildConfigurationValue.Key. This class allows us to compute a fingerprint of the wrapped ImmutableSortedSet, making equality comparisons fast. The number of additional wrapper objects is the number of distinct sets of fragment classes, so 1. (In fact, we don't even need to compute a fingerprint, since reference equality does the job for us here, but we do it just to be conservative.)
This CL has a performance benefit for Bazel currently, but has a bigger performance benefit in the following changes, where there are more BuildConfigurationValue.Key objects to compare.
PiperOrigin-RevId: 183090122
|
|
|
|
|
|
|
| |
`blaze --nomaster_bazelrc --master_bazelrc` now uses the master bazelrc.
RELNOTES: None
PiperOrigin-RevId: 183083839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We'll just replace them with either native support for running tests inside
Docker containers on CI or with VMs running the operating system.
This gets rid of the "let's download 8 GB of Docker images" step when running
`bazel build //...`.
RELNOTES: None.
Closes #4506.
PiperOrigin-RevId: 183078052
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 183069509
|
|
|
|
|
|
|
|
|
| |
Add a test verifying that http_archive from @bazel_tools caches
repositories, also for subsequent queries. Provides a workaround
for #2780.
Change-Id: Ie842c2abf47f42f75e146e454be4ab52efd12ada
PiperOrigin-RevId: 183063093
|
|
|
|
|
|
|
|
| |
and fixes codec in
RunUnderConverter.
PiperOrigin-RevId: 183003383
|
|
|
|
|
|
|
|
| |
ImmutableSortedSet wherever possible, and use a known explicit ImmutableSortedSet in the case of two sets being equal. This is mainly a cosmetic cleanup for the sequel changes.
Also rename test-only methods in SkyframeExecutor to indicate that, and do a drive-by clean-up of a test that reported hard crashes confusingly because it wrapped RuntimeExceptions.
PiperOrigin-RevId: 182984572
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merged object files are needed when we use -flto-unit. It's created
during the LTO indexing step and needs to be passed to the final link.
LLVM already can create merged object files we just need to pass
"-Wl,-plugin-opt,obj-path=" into LLVM gold plugin.
"-flto-unit" emits IR to support LTO unit features needed for CFI (Control
Flow Integrity).
RELNOTES: Add support for merged object files needed for -flto-unit.
PiperOrigin-RevId: 182964781
|
|
|
|
|
|
|
| |
JavaRuntimeInfo.
Change-Id: Ic338dc9b3e5efa2fee92dba722a46cab743db40c
PiperOrigin-RevId: 182919931
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not run "find & chmod" on the extracted files,
because:
(a) it's unnecessary, we can delete them in the
trap statement just fine, and
(b) it takes an impressive 20 minutes on Windows,
probably because process creation is a lot
slower on Windows than on Unixes and each
`chmod` runs as a subprocess of `find`
See https://github.com/bazelbuild/bazel/issues/4503
Change-Id: I47d97f00b875716997c197a51602fb6ea7728109
PiperOrigin-RevId: 182905086
|
|
|
|
|
|
|
|
| |
Fixes #3234.
Rollforward of commit dafe71390340224e06eab0ac7afcebb2f5219f5a with a bugfix
PiperOrigin-RevId: 182903117
|
|
|
|
|
|
|
|
|
|
|
| |
JavaRuleOutputJarsProvider.
Added tests for checking JavaRuleOutputJarsProvider state.
Moved all test cases related to JavaInfo to new file JavaInfoSkylarkApiTest.java
Created RuleBuilder inside JavaInfoSkylarkApiTest to reduce duplication of code.
RELNOTES:none
PiperOrigin-RevId: 182901118
|
|
|
|
|
|
|
|
|
|
| |
Bazel may also depend on external repositories that already contain
build files. When using http_archive from @bazel_tools also support
that use case, by supporting simply omitting `build_file` and
`build_file_contents`.
Change-Id: I40a9b85ae0aba850c73104d2e2fe7f7ee814e093
PiperOrigin-RevId: 182893460
|
|
|
|
|
|
| |
java.util.function.Predicate and move some code that was only called by TestFilter inside it.
PiperOrigin-RevId: 182884550
|
|
|
|
|
|
|
| |
Fixes #4170.
Change-Id: I308ee17eb769dcc6a94b90b1dd6cc2ccbe14e968
PiperOrigin-RevId: 182807196
|
|
|
|
|
|
|
| |
Part of #4442.
Change-Id: I49d6d851787727739f50348df2e2ef48392af479
PiperOrigin-RevId: 182795733
|
|
|
|
|
|
|
| |
This will serve as an alternative to --batch, leaving behind a server without state from the previous build.
RELNOTES: Introduces --[no]keep_state_after_build
PiperOrigin-RevId: 182778500
|
|
|
|
|
|
|
| |
Part of #4442.
Change-Id: I6debbf7cfdf560d2113e736176702c2cd889c0d2
PiperOrigin-RevId: 182763864
|
|
|
|
|
|
| |
owner and fix up BuildConfigurationValue.Key. ConfiguredTargetKey is going to need some modifications to AutoCodec: probably the long-awaited static "create" method.
PiperOrigin-RevId: 182630181
|
|
|
|
|
|
|
| |
https://google.github.io/styleguide/javaguide.html#s3.4.2.1-overloads-never-split
RELNOTES: NONE.
PiperOrigin-RevId: 182626819
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 182579590
|
|
|
|
|
|
|
|
| |
into output files one by one this mostly means that we can start writing the next file while the previous one is still finishing up, and can read and write in parallel.
RELNOTES: None.
PiperOrigin-RevId: 182570961
|
|
|
|
|
|
| |
Also add a new appendFile method on Scratch.
PiperOrigin-RevId: 182558199
|
|
|
|
|
|
|
| |
An upcoming replacement to PathFragment will not have efficient segment semantics, causing code to become unnecessarily inefficient.
RELNOTES: None
PiperOrigin-RevId: 182553098
|
|
|
|
|
|
| |
This makes it clearer that the path fragments in question are relative *to the root*. Confusingly, when the root is absolute, the root relative fragment is also absolute. This makes it a tiny bit clearer that the path fragment may be absolute.
PiperOrigin-RevId: 182544893
|
|
|
|
|
|
| |
path class.
PiperOrigin-RevId: 182526427
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks C++ on gcc 4.8.4 (specifically, TensorFlow: https://github.com/bazelbuild/bazel/issues/4474)
Fixes #4474
*** Original change description ***
When linking mostly-static Linux binaries, link libstdc++.a explicitly.
This allows libstdc++ to be statically linked, which is normally only
possible when invoking GCC as `g++` with the `-static-libstdc++` flag.
Fixes https://github.com/bazelbuild/bazel/issues/2840
See https://github.com/envoyproxy/envoy/issues/415 for additional
background and context.
cc @htuch (for Envoy) and @calpeyser @hlopko (who I talked to earlier about this)...
***
RELNOTES: None.
PiperOrigin-RevId: 182519445
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Local execution has an inherent race condition: if a user modifies a file while an action is executed, then it is impossible for Bazel to tell which version of the file was actually read during action execution. The file may have been modified before or after the tool has read it, or, in the worst case, the tool may have read both the original and the modified version. In addition, the file may be changed back to the original state before Bazel can check the file, so computing the digest before / after may not be sufficient.
This is a concern for both local and remote caches, although the cost of poisoning a shared remote cache is significantly higher, and is what has triggered this work.
Fixes #3360.
We solve this by keeping a reference to the FileContentsProxy, and using that to check for modificaitons before storing the cache entry. We output a warning if this check fails.
This change does not increase memory consumption; Java objects are always allocated in multiples of 8 bytes, we use compressed oops, and the FileArtifactValue currently has 12 bytes worth of fields (excl. object overhead), so adding another pointer is effectively free.
As a possible performance optimization on purely local builds, we could also consider not computing digests at all, and only use the FileContentsProxy for caching.
PiperOrigin-RevId: 182510358
|