| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
message.
RELNOTES: None.
PiperOrigin-RevId: 153372617
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
broken tests
*** Original change description ***
Init absent action configs for CppCompile actions
So far only link actions were initialized in CppLinkActionConfigs. This cl
changes this class to also initialize CppCompile actions. This is needed for
our ongoing work removing hard-coded flags from Bazel and moving them into
Crosstool.
RELNOTES: None.
PiperOrigin-RevId: 153366563
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic is already in Bazel but wasn't available to build rules.
This change makes it available, but still requires data binding's
{build|run}time libraries to be checked into appropriate depot
spots for everything to work.
Followup changes will make those libraries easily available.
Issue: #2694
PiperOrigin-RevId: 153359861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
breaks tests
*** Original change description ***
Extract --sysroot flag from bazel and move it into crosstool
This is an encore of https://github.com/bazelbuild/bazel/commit/6127358c1799d8d83cebbd499edac89f869df41b .
RELNOTES: None.
PiperOrigin-RevId: 153351147
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks internal tests that use nonstandard crosstools
*** Original change description ***
Make C++ archiving use action_configs instead of hardcoded flags
RELNOTES: Use action_config in crosstool for static library archiving, remove ar_flag.
PiperOrigin-RevId: 153344597
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 153223511
|
|
|
|
| |
PiperOrigin-RevId: 153202296
|
|
|
|
|
|
|
| |
to avoid exceeding the command line length limit for libraries
with very large numbers of resources.
PiperOrigin-RevId: 153191465
|
|
|
|
|
|
| |
objc_proto_library without the portable_proto_filters attribute.
PiperOrigin-RevId: 153189663
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
android_binary targets have their own R.java files (built from merging
dependencies and any resources that belong directly to the target). As such,
they don't need inherited R.java files at runtime. Taking these out makes for
smaller APKs and less inheritance from the target's dependencies.
Add a flag to control this behavior. Have it default to continue to include
R.class files as runtime dependencies so we can control rollout of this
behavior.
Add tests of android_binary to ensure the JAR is filtered out as appropriate,
and of android_robolectrictest to ensure that those tests still have access to
the JARs.
RELNOTES: none
PiperOrigin-RevId: 153177074
|
|
|
|
| |
PiperOrigin-RevId: 153161442
|
|
|
|
| |
PiperOrigin-RevId: 153140874
|
|
|
|
| |
PiperOrigin-RevId: 153096906
|
|
|
|
|
| |
RELNOTES: Use action_config in crosstool for static library archiving, remove ar_flag.
PiperOrigin-RevId: 153046587
|
|
|
|
|
|
| |
any extra defines.
PiperOrigin-RevId: 153039146
|
|
|
|
|
|
| |
used.
PiperOrigin-RevId: 153020672
|
|
|
|
|
|
|
|
|
| |
Before this change Bazel was adding this implicitly. But that wasn't
working properly with --incremental_dexing. And that implementation is a
lot messier and bug-prone vs. just including it as a standard dependency.
Issue: #2694
PiperOrigin-RevId: 152956638
|
|
|
|
|
|
|
| |
This issues a configuration transition on the dependencies of the rule, causing deps to be compiled with the appropriate minimum os version.
RELNOTES: None.
PiperOrigin-RevId: 152952168
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first actual user of the config_feature_flag rule, able to actually
set its value (and thus give a point to using it!)
This feature is not fully launched yet, but it is usable in any build
containing this change.
RELNOTES: None.
PiperOrigin-RevId: 152948153
|
|
|
|
|
|
| |
from an apple_binary split transition context. Refactors ProtobufSupport to not rely on ruleContext for dependencies.
PiperOrigin-RevId: 152939984
|
|
|
|
|
|
|
|
| |
tool during incremental dexing
RELNOTES: none
PiperOrigin-RevId: 152838197
|
|
|
|
|
|
|
| |
This follows our CamelCaseInfo naming conventions for providers.
RELNOTES: None.
PiperOrigin-RevId: 152832215
|
|
|
|
| |
PiperOrigin-RevId: 152810023
|
|
|
|
|
|
|
| |
This is an encore of https://github.com/bazelbuild/bazel/commit/6127358c1799d8d83cebbd499edac89f869df41b .
RELNOTES: None.
PiperOrigin-RevId: 152803621
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152800780
|
|
|
|
|
|
|
| |
Default providers can now be used not only to return standard providers values
from a rule implementation function, but also to access these values provided
by other rules.
PiperOrigin-RevId: 152797193
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152793682
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 152782181
|
|
|
|
|
|
|
|
|
|
| |
Previously, there was no configuration transition in the default case.
While this was "convenient" for testing, it makes these tests somewhat inconsistent,
and furthermore invalid once these rules switch to always using a configuration transition
with the inclusion of minimum OS as an attribute.
RELNOTES: None.
PiperOrigin-RevId: 152734307
|
|
|
|
| |
PiperOrigin-RevId: 152714468
|
|
|
|
|
|
|
| |
--j2objc_dead_cdoe_report accepts a label that can generate a dead code report as argument. If specified, Blaze should pass "--dead-code-report path/to/dead/code/report" to J2ObjC.
RELNOTES: None.
PiperOrigin-RevId: 152712841
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously multidex did not work in Bazel because it required a dependency on
zip, which we do not ship with Bazel. Then the
--experimental_android_use_singlejar_for_multidex flag was added to use a
different tool that is included with Bazel for multidex. This change sets that
flag to be the default.
Fixes https://github.com/bazelbuild/bazel/issues/1936
RELNOTES: android_binary multidex should now work without additional flags.
PiperOrigin-RevId: 152712301
|
|
|
|
|
| |
Change-Id: I407240708f4aacc89ec5c00bf3e8ff46a1d6d6d6
PiperOrigin-RevId: 152692981
|
|
|
|
|
|
|
| |
It doesn't make sense, and is ignored anyway.
RELNOTES: None.
PiperOrigin-RevId: 152667088
|
|
|
|
| |
PiperOrigin-RevId: 152654844
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 152523635
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Causes Blaze release failures.
*** Original change description ***
Genrules only depend on the host JDK if they have Java make variables.
e.g.: cmd = "$(JAVA) foo.java ..."
PiperOrigin-RevId: 152516143
|
|
|
|
|
|
|
| |
necessary with dynamic configurations
RELNOTES: None.
PiperOrigin-RevId: 152515642
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives the ability to select on config_feature_flags. They still
have not been publicly documented, because there's no way to set them.
But, progress.
config_setting still needs to have either values or flag_values; it cannot
have both be empty. However, values is no longer mandatory, nor must it be
nonempty (as long as flag_values is set nonempty).
RELNOTES: None.
PiperOrigin-RevId: 152515036
|
|
|
|
|
|
|
| |
All android_sdk rules are required to have the apksigner binary, which was not included in the build tools until version 24.0.3. So this check is no longer necessary. Instead, we check in AndroidSdkRepositoryFunction.
RELNOTES: None
PiperOrigin-RevId: 152498753
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152416858
|
|
|
|
|
| |
Change-Id: Ied06efd4bc68f604975b1e8e3fc70817a577d563
PiperOrigin-RevId: 152412538
|
|
|
|
|
| |
.collectCompileTimeDependencyArtifacts instead of retrieving the JavaCompilationArgsProviders twice and checking for duplicates.
PiperOrigin-RevId: 152398536
|
|
|
|
| |
PiperOrigin-RevId: 152356545
|
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 152340847
|
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 152291766
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes Bazel work with data binding runtime libraries 1.3.1
and buildtime libraries 2.3.1.
The biggest change is to configure the annotation processor with javac
annotation processor flags ("-Aflag=value") instead of directly through
annotations in a template Java file.
PiperOrigin-RevId: 152282448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConfigSetting was previously in analysis/config, where it was slightly out
of place (as it is a rule, not an integral part of the analysis backend).
This is also necessary to integrate it with ConfigFeatureFlag, as otherwise
this would be a circular dependency (analysis/config <-> rules/config).
ConfigFeatureFlagRule itself has been moved into ConfigRuleClasses, where
it can use the ConfigBaseRule and the nonconfigurable reason from the other
configuration rules.
RELNOTES: None.
PiperOrigin-RevId: 152275823
|
|
|
|
| |
PiperOrigin-RevId: 152264528
|
|
|
|
|
|
| |
e.g.: cmd = "$(JAVA) foo.java ..."
PiperOrigin-RevId: 152263822
|