| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
This is useful for dealing with all the existing implementations in the face of
interface changes that are irrelevant.
RELNOTES: None
PiperOrigin-RevId: 155525021
|
|
|
|
|
|
| |
See breakage @ http://ci.bazel.io/view/Bazel%20bootstrap%20and%20maintenance/job/Bazel/JAVA_VERSION=1.8,PLATFORM_NAME=freebsd-11/1481/console.
PiperOrigin-RevId: 155517063
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 155507750
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exoblaze compatibility mode.
The functional change in this CL is that java_mutable_proto library now uses the "correct" java semantics depending on which blaze it is installed in. This required some refactoring of the ExoblazeRulesModule and ExoblazeRuleClassProvider to make them able to have parameters (like java semantics).
To simplify module installation this change also extracts strategy management from being in "rules" modules to their own modules. Now modules don't need to inherit from each other anymore but can be installed alongside each other.
It seems to be impossible to test the compatibility mode in TAP: java_mutable_proto library requires both Linux binaries (Blaze itself) and macOS binaries (ijar) which cannot both be inputs to the test today. So instead I manually tested this change in both Exoblaze native and compatibility mode.
RELNOTES: None.
PiperOrigin-RevId: 155507096
|
|
|
|
|
|
|
| |
The removes redundancy from the logic around calculating the sysroot (and was been a TODO since 2014!)
RELNOTES: None
PiperOrigin-RevId: 155506682
|
|
|
|
|
|
|
|
|
| |
This unifies our code to use just one standard implementation to get the
entire expanded input files for a Spawn, including from Filesets and
Runfiles.
Change-Id: I1e286508adf0a9aeddf70934b010e6fcc144c4a7
PiperOrigin-RevId: 155497273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Looks like it broke stuff - the presubmit bypass was added by accident.
*** Original change description ***
Add a custom interface for cache hit processing in actions
The new interface mirrors ActionExecutionContext, but is restricted to exactly
the parts used right now. I did consider using ActionExecutionContext, but it
contains some parts that we don't want to make available for cache hits.
The end goal is to allow the build event stream access to artifact metadata,
in particular for TestResult and TestSummary events, which in turn requires
making artifact metadata available when the TestRunnerAc...
***
PiperOrigin-RevId: 155493797
|
|
|
|
|
|
|
|
|
|
|
| |
Hardlinks are problematic due to not working across filesystem
boundaries and causing Bazel to do lots of I/O because it has to create
a hardlink and a symlink for each input file.
This improves performance of Bazel building itself by 10% on my system.
Change-Id: I8acb77053de875160a046e38624735ed18375bed
PiperOrigin-RevId: 155493583
|
|
|
|
|
|
|
|
|
| |
This gives us much improved process management, because Bazel can now
reliably kill child processes of spawns via their process group and wait
for them to exit.
Change-Id: Ib3cb20725b3c569aa5b317a69d7682f5774707b0
PiperOrigin-RevId: 155493511
|
|
|
|
|
|
|
|
| |
In multi-configuration builds, test can be run for different configurations as well. So
we have to report the configuration for each test as well.
Change-Id: I939cce7464823fbcd3c7161a50b41b94bbed8812
PiperOrigin-RevId: 155493397
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new interface mirrors ActionExecutionContext, but is restricted to exactly
the parts used right now. I did consider using ActionExecutionContext, but it
contains some parts that we don't want to make available for cache hits.
The end goal is to allow the build event stream access to artifact metadata,
in particular for TestResult and TestSummary events, which in turn requires
making artifact metadata available when the TestRunnerAction is a cache hit.
PiperOrigin-RevId: 155492447
|
|
|
|
| |
PiperOrigin-RevId: 155491277
|
|
|
|
|
|
|
|
|
|
|
| |
In multi-architecture builds, a target might be built several times,
for the different architectures. Make the target completion events for
those distinguishable by indicating the architecture for which the target
was built. Also add the needed event for the expansion of a target to
target-configuration pairs.
Change-Id: I95ef2c81166077163dd686db4671f672160efe1d
PiperOrigin-RevId: 155491076
|
|
|
|
|
|
|
|
|
| |
This gives us better reliability for detecting file changes; especially in
cases where tools intentionally do not update mtime.
Fixes #1525.
PiperOrigin-RevId: 155490849
|
|
|
|
|
| |
Change-Id: Idc023f3a8c1c3b60d3f3f23a579a5eccb92d074d
PiperOrigin-RevId: 155487527
|
|
|
|
|
| |
Change-Id: I1522c364a157ee0a144ab83eca54e419142c03b1
PiperOrigin-RevId: 155484109
|
|
|
|
|
|
| |
use select statements.
PiperOrigin-RevId: 155480011
|
|
|
|
|
|
|
|
| |
By this time (6 months later) Bazel clients should no longer need
this.
Change-Id: Ib058065a0ff3eedc777e95c7d06602ca6744d42a
PiperOrigin-RevId: 155478543
|
|
|
|
|
|
|
|
| |
There's no need to make it explicitly readable, because the entire host
filesystem is readable anyway.
Change-Id: I6a63cc93b600250c1c8828ef8d1c9d6133b671d7
PiperOrigin-RevId: 155477093
|
|
|
|
|
|
|
| |
Before it was omitting category titles / section breaks if the first option of the new category happened to be undocumented.
RELNOTES: None
PiperOrigin-RevId: 155458981
|
|
|
|
|
|
| |
Instead of using ImmutableMap, we share the keys between all provider maps with an identical key set.
PiperOrigin-RevId: 155432135
|
|
|
|
|
|
|
| |
binary provider instead of the apple_binary rule.
RELNOTES: None.
PiperOrigin-RevId: 155430332
|
|
|
|
|
|
| |
failures.
PiperOrigin-RevId: 155425839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `structured_resources` path stemming used by `objc_library` and
`objc_bundle_library` no longer breaks if one of these rules tries to
reference a label with an explicit repository prefix. Previously,
using "@foo//bar:baz" in such a rule would fail because the individual
files would retain their "external/foo/" prefix but the owner path
against which those files were relativized would not have it because
of the use of getPackageFragment() instead of
getPackageIdentifier().getSourceRoot().
RELNOTES: None.
PiperOrigin-RevId: 155409464
|
|
|
|
|
|
|
|
| |
The "concurrent" bit was supposedly around for testing purposes, but who knows if it even works anymore. Making other callsites explicitly state their ErrorClassifier gets us down to two constructors, one of which can delegate to the other.
I think having both these constructors is useful because there's a linkage between creating a new executor service and specifying that the AQV should shut down the service at the end of the visitation. And using a static create() method doesn't work because of AQV's inheritance model.
PiperOrigin-RevId: 155406771
|
|
|
|
|
|
|
|
|
| |
Make fields visibility/accessors more idiomatic. Prefer accessors that give a full map of the bindings and inherited bindings, rather than just the keys.
Also increase visibility of some accessors on Mutability.
RELNOTES: None
PiperOrigin-RevId: 155393780
|
|
|
|
|
|
|
|
|
| |
It provides a single and clean way to output warning messages,
and replaces the fprintf(stderr, "Warning: ...\n") or
fprintf(stderr, "WARNING: ...\n") calls.
Change-Id: I2f8a8f659085b9e57a08b5208a8b8f683a7cd72c
PiperOrigin-RevId: 155386233
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rjars = java_common.create_provider(
compile_time_jars = depset(),
runtime_jars = merged_runtime.transitive_runtime_deps,
)
This avoids linearizing the runtime_deps (with the corresponding memory
issues). Must be a JavaProvider for proper interaction with native rules
but cannot just be a simple merge since runtime_deps should not
contribute to compile of the dependent rules.
Note, this will effect a change of the already-released API; however,
function marked as undocumented in an experimental object....
Change-Id: I54542a5d57c75e762b2276e0a1988816901a0def
PiperOrigin-RevId: 155384266
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 155382994
|
|
|
|
|
| |
Change-Id: I1bc1901ea7cd9a5b93c280ec0ff8ac0d10959a09
PiperOrigin-RevId: 155381163
|
|
|
|
|
| |
Change-Id: Iad1e07ad55d5304d7c3dbb8bdab856728a91432d
PiperOrigin-RevId: 155375893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rollforward with fix
To have stdout/stderr in the BuildEventStream, the BuildEventStreamerModule
registers a listener that accumulates the values for the streamer to
collect it and regularly send it over the stream. As we have to also catch
stdout/stderr that happens early in the build, we have to register the listener
before(!) the options are parsed; therefore it is registered unconditionally.
Now, if there is no streamer created after parsing the options there is no
one to collect the data and it grows indefinitely. Fix this, by disabling
the collection in this case.
*** Original change description ***
Automated g4 rollback of commit 9e37b2e52d6e42eec15712942c7f208b64c651e5.
*** Reason for rollback ***
Results in NegativeArraySizeExceptions when there's a high volume of data.
*** Original change description ***
BEP: Report stdout/stderr
By recording registering a properly synchronized OutErr as listener
and providing it as OutErrProvider to the BuildEventStreamer.
Change-Id: Id553fcdb85327be28561634268511304fcc2ad3f
PiperOrigin-RevId: 155374710
|
|
|
|
|
|
|
|
|
| |
This is possibly a nit, but we don't want to reuse flag names in the future, so it's a good idea to include what the flag *does* in the name as opposed to just the feature it affects, in case the same feature is changed multiple times. Updated javadoc for incompatible change system to say so.
This rename is ok because these flags have only been submitted over the past couple days.
RELNOTES: None
PiperOrigin-RevId: 155371363
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, silently ignore them in the same way we do for rules to which
aspects are not applicable.
In the future aspects will gain the ability to apply to, and propagate
through, files.
RELNOTES: None.
PiperOrigin-RevId: 155369925
|
|
|
|
|
|
|
|
| |
There's no need to check for the OS version, as we can just try to use
sandbox-exec and if it works, we're good.
Change-Id: I7fe9a0b55856c646da915a2872531f050a25b110
PiperOrigin-RevId: 155368707
|
|
|
|
|
|
|
|
|
|
| |
In preparation to support multi-configuration builds, provide infrastructure
allowing build events to reference BuildConfigurations. The streaming mechanism
will ensure that build configurations are introduced in the stream before being
referenced for the first time.
Change-Id: I6b96fbebc76a05eff4f75a07e8a9cfbcd57f9c22
PiperOrigin-RevId: 155368666
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(fallback only).
On macOS the processwrapper-sandbox will be used when the darwin-sandbox doesn't
work. Most notably this is the case for nested sandboxing, e.g. Bazel running
Bazel inside an integration test.
Also includes a fix to pull in some extra environment vars on macOS, similar to
what DarwinSandboxedStrategy and StandaloneSpawnStrategy already do. Without
this the processwrapper-sandbox seems to occasionally cause ObjC builds (and two
of our tests) to fail.
Change-Id: Ic7462080caf56d9bb98e2f3765bd37853b01632b
RELNOTES: Sandboxing is now enabled by default on FreeBSD (via processwrapper-sandbox).
PiperOrigin-RevId: 155366728
|
|
|
|
|
| |
Change-Id: I1355c2448cb6cbbcdbace81051a7beb8659f1f00
PiperOrigin-RevId: 155366727
|
|
|
|
|
| |
Change-Id: I43dfd979aee0c510ec18b479f2a6bd55562b3fc0
PiperOrigin-RevId: 155361450
|
|
|
|
|
| |
Change-Id: I68797947905166b71a58d8332be18fc7bd6de30d
PiperOrigin-RevId: 155360327
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-1 is not a valid port number and thus do not mean "no gRPC command server".
If you try to pass -1 to command_port you get:
$ bazel --command_port=-1 build //...
Invalid argument to --command_port: '-1'.
Must be a valid port number or 0.
Change-Id: I6c17167f6a285b21fcd064cea8bdc7e6770ac984
PiperOrigin-RevId: 155352835
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 155321388
|
|
|
|
|
|
|
|
|
|
|
|
| |
the general collection interface (e.g. List) with an immutable type (e.g. ImmutableList).
For constant field declarations, you should use the immutable type (such as ImmutableList) instead of the general collection interface type (such as List). This communicates to your callers important semantic guarantees ([]
For more info, see:[]
Cleanup change automatically generated by error-prone refactoring //third_party/java_src/error_prone/project/core/src/main/java/com/google/errorprone/bugpatterns:MutableConstantField_refactoring on targets //third_party/bazel/...
PiperOrigin-RevId: 155305768
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Results in NegativeArraySizeExceptions when there's a high volume of data.
*** Original change description ***
BEP: Report stdout/stderr
By recording registering a properly synchronized OutErr as listener
and providing it as OutErrProvider to the BuildEventStreamer.
Change-Id: Id553fcdb85327be28561634268511304fcc2ad3f
PiperOrigin-RevId: 155252872
|
|
|
|
|
|
|
|
|
|
| |
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: 155231021
|
|
|
|
| |
PiperOrigin-RevId: 155223937
|
|
|
|
| |
PiperOrigin-RevId: 155223580
|
|
|
|
|
|
|
|
|
|
|
| |
RELNOTES: Adds a sha256 attribute to git_repository and new_git_repository.
This can only be used if the remote is a public GitHub repository. It forces
Bazel to download the repository as a tarball, which will often be faster and
more robust than cloning it.
#2147.
PiperOrigin-RevId: 155223382
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rule is responsible for building the target and instrumentation APKs used by an Android instrumentation test. If they are provided as APKs (e.g. from an android_binary or a genrule) they will be used as is. If they are provided as libraries, APKs will be created. This CL does not actually implement building target and instrumentation APKs from libraries, that will come in a follow-up CL as it will require some heavy refactoring of AndroidBinary.java.
Follow-up CLs will add features such as repackaging the APKs to remove duplicate classes, reproguarding the target APK with the test code, validating that the target and instrumentation APKs were signed with the same debug key and verifying that instrumentation stanza appears in the instrumentation APKs manifest.
Note that this CL does _not_ install the rule in the BazelRuleClassProvider, so
this CL does not make it usable by anyone. Once the other android testing rules are ready, I will install them all.
One small step towards https://github.com/bazelbuild/bazel/issues/903.
RELNOTES: None
PiperOrigin-RevId: 155220900
|
|
|
|
| |
PiperOrigin-RevId: 155209610
|