| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add compile_jars Skylark accessor to JavaProvider. This outputs the
non-recursive set of jars needed to build with this target. Allows
Skylark tools to get the same set of compile_jars that JavaLibrary is
getting.
Added test that verifies Skylark was getting lists from both
compile_jars and transitive_runtime_jars of the expected length. Then,
verified (via test code) those nested sets were identical to the ones
provided by the java_library.
To reviewers:
First, would like to add documentation flags to these fields in
JavaProvider. Is it possible, instead of adding them to this map to
follow use the @SkylarkCallable annotation to expose methods on
JavaProvider instead? It would then also be nice to mark these as
experimental since won't really know the final API until
java_skylark_library sandwich is done.
I also tested this locally via bazel build //src:bazel and then doing
~/bazelsandbox/bazel/bazel-bin/src/bazel test SomeTarget in a different
repo that had a .bzl file trying to use compile_jars.
Change-Id: I1779c1b6303f36e50076c3479bfcb15a25aa95d8
PiperOrigin-RevId: 155191816
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the build event protocol to be able to report configurations;
in this way, we can distinguish, for which configuration a target
completed, a test passed, etc.
Note that this change allows for an additional expansion step: patterns
can be expanded to unconfigured targets that get configured in a
separate expansion step.
Change-Id: I31442796f57fe9acebc3cb5044e03087c4e4fd59
PiperOrigin-RevId: 155186365
|
|
|
|
|
|
|
|
|
|
| |
Move the position of the timestamp to the beginning of the line to
have a more readable log. Also, show the timestamp for progress as
well. While there, reduce timestamp to second precision, to reduce
noise.
Change-Id: Ibfa6caca2e0d207f54e3660bccbf894bba3c5ae3
PiperOrigin-RevId: 155181731
|
|
|
|
|
|
| |
This CL also makes CcToolchain responsible for adding the sysroot to CC_FLAGS.
PiperOrigin-RevId: 155171725
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/509.
Example output:
```
$ bazel build //:all
INFO: Found 1 target...
ERROR: /usr/local/google/home/ajmichael/.cache/bazel/_bazel_ajmichael/7fcc7480abc634522e5c0cfe6b85b583/external/bazel_tools/tools/android/BUILD:236:1: Executing genrule @bazel_tools//tools/android:no_android_sdk_repository_error failed: Process exited with status 1 [sandboxed].
This build requires an Android SDK. Please add the android_sdk_repository rule to your WORKSPACE.
Use --strategy=Genrule=standalone to disable sandboxing for the failing actions.
Target //:lib failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.327s, Critical Path: 0.10s
```
RELNOTES: Attempting to build an Android target without setting up android_sdk_repository will now produce a helpful error message.
PiperOrigin-RevId: 155158667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rule simply provides a shell script that is run on a device as part of a
test which can come from an input file or as a string command.
It also takes a list of APKs that need to be installed before the fixture can
be run.
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: 155155984
|
|
|
|
| |
PiperOrigin-RevId: 155125357
|
|
|
|
|
|
|
|
| |
Re-organize ObjcLibraryTest and ExperimentalObjcLibraryTest ->
LegacyObjcLibraryTest and CrosstoolObjcLibraryTest, according to the pattern used in
the other unit tests.
PiperOrigin-RevId: 155120143
|
|
|
|
|
|
|
|
|
| |
If the list of direct deps is empty, it's either because the action doesn't
distinguish between direct and transitive deps, or because the target has no
deps at all. The 'direct classpath optimization' can still be applied in the
latter case.
PiperOrigin-RevId: 155112465
|
|
|
|
|
|
|
| |
AttrFunction and LabelsFunction are also made public.
RELNOTES: None
PiperOrigin-RevId: 155108260
|
|
|
|
| |
PiperOrigin-RevId: 155105523
|
|
|
|
|
|
|
|
| |
Also, repository_name() replaces REPOSITORY_NAME.
In .bzl files, they are prefixed with "native.".
RELNOTES: None.
PiperOrigin-RevId: 155102221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quick overview:
- provide a dynamic interface for getting the artifact owner
configuration
- provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace
the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually
we'll remove the rule class configurator interface entirely.
This doesn't actually turn dynamic LIPO on. So the direct effect of
this change should be a no-op. The flip will come in a followup
change. For now, dynamic LIPO can be triggered with
--experimental_dynamic_configs=notrim.
PiperOrigin-RevId: 155096056
|
|
|
|
|
| |
Usage: --incompatible_dict_plus=true (the default value is false).
PiperOrigin-RevId: 155094639
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the compilation involves API-generating annotation processors none of the
features in JavaHeaderCompileAction are necessary. Instead, just use a
SpawnAction.
Also set a different mnemonic (JavacTurbine) to track how often this happens,
and to better understand the performanec breakdown between javac-turbine and
regular turbine actions.
PiperOrigin-RevId: 155094632
|
|
|
|
|
|
|
|
|
| |
This helps readability, particularly since we also have "isImmutable" for SkylarkValues and in EvalUtils. I considered changing those to isFrozen as well, but we can leave it as-is since the terminology of freezing doesn't necessarily apply to non-Freezable things.
Also rephrased some javadoc.
RELNOTES: None
PiperOrigin-RevId: 155090987
|
|
|
|
|
| |
Usage: --incompatible_list_plus_equals=true (the default value is false).
PiperOrigin-RevId: 155084916
|
|
|
|
|
|
|
| |
re-implement what we get for free in the base class.
RELNOTES: None
PiperOrigin-RevId: 155080289
|
|
|
|
|
|
|
|
|
| |
EnableLipoTransition provides the dynamic equivalent for LIPO_ON_DEMAND.
ContextCollectorOwnerTransition provides the ability to get the "owner"
configuration from the LIPO collector configuration.
PiperOrigin-RevId: 155079187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keyword-only syntax is when a parameter happens after the `*` paramter, e.g.
def foo(a, *, b): pass
or:
def foo(a, *b, c): pass
The syntax is not compatible with Python 2 (it's supported only in Python 3),
and breaking tooling based on Python2.
RELNOTES:
Keyword-only syntax in a function definition is deprecated
(e.g. `def foo(a, *, b)` or `def foo(a, *b, c)`) and will be removed in the future.
PiperOrigin-RevId: 155071704
|
|
|
|
|
|
|
| |
This was implicitly adding --use_singlejar_apkbuilder, which was not the intended effect.
RELNOTES: None
PiperOrigin-RevId: 155022967
|
|
|
|
|
|
|
|
|
| |
This is a standalone library for loading packages. It is intended to be used by clients outside of Bazel (for now, Kythe).
Perform BazelPackageLoader#loadPackage in the testing hook used in all of Bazel's unit tests and integration tests. This gives us very good test coverage for BazelPackageLoader.
RELNOTES: None
PiperOrigin-RevId: 155004070
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Remove obsolete originalOptions field. This was originally added to
support "parent" transitions, which supported config1 -> config2 -> config1
transitions by having config2 store config1's options.
The purpose of this feature was to support LIPO (which has a DATA -> TARGET
transition). But https://github.com/bazelbuild/bazel/commit/ff29c0b39cf936a2699b05edd54f483f1a037d93
makes this unnecessary.
2) Support the "disable actions" feature of the LIPO context collector configuration.
Putting this in BuildOptions make this dynamic config-compatible.
This change intentionally doesn't add disableOptions to BuildOptions.equals() or
BuildOptions.hashCode(). It'd be great to do that. But that has semantic consequences.
And we've run into really tricky bugs in the past with dynamic configurations and
BuildOptions.equals / BuildConfiguration.equals. So it's best to experiment with
that in its own change.
PiperOrigin-RevId: 154999718
|
|
|
|
|
|
|
| |
RELNOTES[INC]: Blaze no longer generates xcode projects. Use tulsi.bazel.build
instead.
PiperOrigin-RevId: 154997997
|
|
|
|
|
|
|
| |
This fixes a bug that put them out of sync from how all other
attributes manage the host configuration.
PiperOrigin-RevId: 154992583
|
|
|
|
|
|
| |
wrapper objects: for OwnedArtifacts, which are the most numerous during builds, and for Labels for TransitiveTraversalValues, which are the most numerous during queries.
PiperOrigin-RevId: 154989520
|
|
|
|
|
|
| |
updates --experimental_one_version_enforcement from a boolean flag to a 3-state enum (OFF, WARNING, ERROR).
PiperOrigin-RevId: 154978203
|
|
|
|
|
| |
Usage: --incompatible_depset_constructor=true (the default value is false).
PiperOrigin-RevId: 154971526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Filter out conflicting flag policies for applicable commands. Only enforce the filtered, applicable policy.
*** Original change description ***
Automated g4 rollback of commit aa7f9307636d38cbb93a03acac8f4c59adfa0ee8.
*** Reason for rollback ***
Broke --experimental_inmemory_dotd_files
*** Original change description ***
Filter out conflicting flag policies before invocation policy enforcement.
This is to minimize the likelihood of obscure policy conflict. Now, the last policy on a flag (after policy expansion) will be the only one in the "canonical" invocation policy. There should be no reason for explicitly setting multiple policies on a single flag, but if an expansion flag is policy'd and one of its children has a more specific policy on it, make sure that the policy on the child flag is after the policy on the expansion flag.
Note that this restriction (only the last policy gets applied) also applies for repeatable flags. Make sure all values being set to a repeatable flag are set in a single SetValue operation, with multiple flagValues set.
PiperOrigin-RevId: 154969189
|
|
|
|
|
|
|
| |
Work towards #2880.
Change-Id: I7b661e368c0bd60fc6bcc10c7c1d63b82ba9702e
PiperOrigin-RevId: 154957882
|
|
|
|
|
|
| |
Otherwise they're read as HTML tags and "invisible." Oops.
PiperOrigin-RevId: 154956817
|
|
|
|
|
|
|
|
|
| |
crosstool case.
To make the ios_framework_binary case to pass, the apple crosstool transition
needs to be applied to that rule.
PiperOrigin-RevId: 154949950
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
The experiment did not succeed. It is valid for the fallback to succeed if
the original failure was due to a Strict Java Deps error, so enabling
this feature as it is currently implemented is not possible.
PiperOrigin-RevId: 154948042
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 154943665
|
|
|
|
|
|
|
|
| |
By recording registering a properly synchronized OutErr as listener
and providing it as OutErrProvider to the BuildEventStreamer.
Change-Id: Id553fcdb85327be28561634268511304fcc2ad3f
PiperOrigin-RevId: 154943162
|
|
|
|
|
|
|
|
|
| |
Almost every target has an OutputGroupProvider. Putting an
("output_groups", value) pair into SkylarkProviders creates an
unneccessary map. This CL removes it.
RELNOTES: None.
PiperOrigin-RevId: 154940624
|
|
|
|
|
|
|
|
| |
Almost every target has an OutputGroupProvider. Do not create another
Key->Provider map just for it.
RELNOTES: None.
PiperOrigin-RevId: 154937690
|
|
|
|
| |
PiperOrigin-RevId: 154931201
|
|
|
|
|
|
|
| |
no-op, and default behavior to on since it has been on in the global blazerc for awhile now.
RELNOTES: Deprecate use_singlejar_for_proguard_libraryjars and force behavior to always on.
PiperOrigin-RevId: 154890445
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 154877525
|
|
|
|
|
|
|
|
| |
Add static methods to return target kinds of InputFile and OutFile, as well as
suffix of target kind of Rule.
RELNOTES: None
PiperOrigin-RevId: 154866926
|
|
|
|
| |
PiperOrigin-RevId: 154860105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets users specify that their test needs a minimum of <n> CPU cores
to run and not be flaky. Example for a reservation of 4 CPUs:
sh_test(
name = "test",
size = "large",
srcs = ["test.sh"],
tags = ["cpu:4"],
)
This could also be used by remote execution strategies to tune their
resource adjustment.
RELNOTES: You can increase the CPU reservation for tests by adding a "cpu:<n>" (e.g. "cpu:4" for four cores) tag to their rule in a BUILD file. This can be used if tests would otherwise overwhelm your system if there's too much parallelism.
PiperOrigin-RevId: 154856091
|
|
|
|
|
|
|
|
| |
Add an event reporting the workspace status as key-value pairs reported
via the workspace_status_command.
Change-Id: I5791551798a594bc2465f483eb97f9d4fd4c7cfd
PiperOrigin-RevId: 154845224
|
|
|
|
|
|
| |
--print-symbol-counts.
PiperOrigin-RevId: 154843561
|
|
|
|
|
| |
RELNOTES: 'output_groups' and 'instrumented_files' cannot be specified in DefaultInfo.
PiperOrigin-RevId: 154842022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Original CL was rolled backed incorrectly. See post-submit discussion on http://https://github.com/bazelbuild/bazel/commit/7beadb7277453efec7e12b925005e7f0e003b592.
*** Original change description ***
Automated g4 rollback of commit 38b835097f9ae9a6062172b8a33ec2e2d1edde20.
*** Reason for rollback ***
Breaking Bazel build on linux, see http://ci.bazel.io/job/bazel-tests/733/
Repro: bazel build //src/test/java/com/google/devtools/build/lib:packages_test
Found by bisecting.
*** Original change description ***
Only allocate some formerly frequently allocated PathFragment objects once.
This reduces both gc churn and retained memory usage.
RELNOTES: None
PiperOrigin-RevId: 154839279
|
|
|
|
|
|
|
| |
as it corrupts its stdout
RELNOTES: None
PiperOrigin-RevId: 154838603
|
|
|
|
|
|
|
|
| |
The SpawnInputExpander can return null action inputs to indicate that we
should create an empty file at the corresponding location, without a
corresponding input file.
PiperOrigin-RevId: 154832564
|
|
|
|
|
|
| |
RELNOTES[INC]: objc_xcodeproj has been removed, use tulsi.bazel.build instead.
PiperOrigin-RevId: 154829733
|