| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
This brings 1.2x speedup to clean local Android builds.
Fixes https://github.com/bazelbuild/bazel/issues/5771
RELNOTES: For Android incremental dexing actions, Bazel now persists its DexBuilder process across individual actions. From our benchmarks, this results in a 1.2x speedup for clean local builds.
PiperOrigin-RevId: 208546936
|
|
|
|
|
|
|
|
|
| |
implement it.
Also clarify the behavior of the expand_template API in the presence of multiple-substitutions.
RELNOTES: None
PiperOrigin-RevId: 202719656
|
|
|
|
|
|
|
|
| |
Instead, add some simple APIs to ExecutorBuilder and inline all the previous
subclasses into their corresponding modules. This removes a bunch of
boilerplate.
PiperOrigin-RevId: 200017162
|
|
|
|
|
|
|
|
|
| |
These have all had a chance to be categorized with the OptionDocumentationCategory enum, and the help output already uses the enum-grouped format.
The "incompatible changes" category has meaning for --all_incompatible_changes and will be removed separately.
RELNOTES: None.
PiperOrigin-RevId: 190773778
|
|
|
|
|
|
|
|
| |
A few help messages were missing a space after the period at the end of a sentence.
Closes #4094.
PiperOrigin-RevId: 177282132
|
|
|
|
|
|
|
| |
The option filters proto dependency can be removed from the OptionsParser. This is in response to option parser users that want to avoid the bazel-internal proto file in their dependencies.
RELNOTES: None.
PiperOrigin-RevId: 162249778
|
|
|
|
|
|
|
|
| |
Resolves #2571
Closes #3316.
PiperOrigin-RevId: 161930376
|
|
|
|
|
|
|
|
| |
Move the default from the annotation to every mention. This makes the incompleteness explicit. Will add the defaults to test targets in a separate change.
Once all dependencies are cleaned up, the Option annotation will no longer allow options without the documentationCategory or effectTag, to prevent new options being added without categories while we migrate to the new option categorization.
PiperOrigin-RevId: 160281252
|
|
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
|