| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
Issue like #2939 are impossible to debug due to missing
jvm.log, make the test framework print it before dying if
the error log output the jvm.log
Fixes #2939 (at least the part we can act on).
PiperOrigin-RevId: 155192458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
We use fail pretty early in the script and not having
the fail function leads to non useful message about
the fail function not existing.
Fixes #2949.
PiperOrigin-RevId: 155186880
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
"server.log" is not written anymore, what goes in now is:
cmdline, jvm.out and server.starttime.
Change-Id: I81b8c1d2647001e2c9c2bf3f1fc304d348033ef3
PiperOrigin-RevId: 155174690
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Since https://github.com/bazelbuild/bazel/issues/2709 was fixed, this CL also enables ParsedAndroidDataTest.
RELNOTES: None
PiperOrigin-RevId: 155155095
|
|
|
|
|
|
| |
The file is AbstractPackageLoaderTest.java not AbstractBazelPackageLoaderTest.java.
PiperOrigin-RevId: 155138964
|
|
|
|
| |
PiperOrigin-RevId: 155131707
|
|
|
|
|
|
|
| |
Also, open source two more tests.
RELNOTES: None
PiperOrigin-RevId: 155129416
|
|
|
|
| |
PiperOrigin-RevId: 155125357
|
|
|
|
|
|
| |
(http://ci.bazel.io/job/bazel-tests/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/lastBuild/console).
PiperOrigin-RevId: 155122394
|
|
|
|
|
|
|
|
| |
Re-organize ObjcLibraryTest and ExperimentalObjcLibraryTest ->
LegacyObjcLibraryTest and CrosstoolObjcLibraryTest, according to the pattern used in
the other unit tests.
PiperOrigin-RevId: 155120143
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 155113548
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/2709
RELNOTES: None.
PiperOrigin-RevId: 155097576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
to ensure outputs from any previous local builds are discarded.
To cherry-pick for #2692.
Fixes #2941
PiperOrigin-RevId: 155089391
|
|
|
|
| |
PiperOrigin-RevId: 155087895
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Change-Id: If79da71d2939517724d92cbe470173b5d68e3019
PiperOrigin-RevId: 155075510
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
if (!source_specified) {
^
src/main/tools/linux-sandbox-options.cc:126:8: note: 'source_specified' was declared here bool source_specified;
^
Closes #2735.
PiperOrigin-RevId: 155067584
|
|
|
|
| |
PiperOrigin-RevId: 155063811
|
|
|
|
|
|
| |
To be cherry-picked for #2692.
PiperOrigin-RevId: 155063394
|
|
|
|
|
|
|
| |
This was implicitly adding --use_singlejar_apkbuilder, which was not the intended effect.
RELNOTES: None
PiperOrigin-RevId: 155022967
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 155005554
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 155003333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
platform types.
RELNOTES: None.
PiperOrigin-RevId: 154993630
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
com.android.builder.internal
* Fixed formatting.
RELNOTES: None
PiperOrigin-RevId: 154973113
|
|
|
|
|
| |
Usage: --incompatible_depset_constructor=true (the default value is false).
PiperOrigin-RevId: 154971526
|
|
|
|
|
|
|
| |
to resolve classes hierarchy to determine whether a type is an exception type.
RELNOTES:n/a
PiperOrigin-RevId: 154971455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|