| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 178074510
|
|
|
|
|
|
|
|
|
| |
since it is not allowed to have cc_library dependencies.
Fixes #4237
RELNOTES: None.
PiperOrigin-RevId: 178074296
|
|
|
|
|
|
|
|
|
| |
If a rule needs these template variables, it will need to declare a dependency on them in the future by adding @bazel_tools//tools/jdk:current_java_runtime to its toolchains= attribute.
RELNOTES[INC]: In order to access the template variables $(JAVA) and $(JAVABASE), @bazel_tools//tools/jdk:current_java_runtime needs to be added to the toolchains= attribute from now on.
RELNOTES: None.
PiperOrigin-RevId: 178070807
|
|
|
|
|
|
|
| |
ExecutionStatisticsProvider.
RELNOTES: None.
PiperOrigin-RevId: 178056182
|
|
|
|
|
|
|
|
| |
incremental_dexing attribute documentation.
RELNOTES: None.
PiperOrigin-RevId: 178047799
|
|
|
|
|
|
| |
This can occur in genqueries when a referenced package isn't in the scope.
PiperOrigin-RevId: 178038701
|
|
|
|
|
|
|
| |
1: Allow both in the same build (before, just one would trigger)
2: Don't check environment defaults from other groups, since neither
flag asserts any expectations on those groups
PiperOrigin-RevId: 178026699
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 178013335
|
|
|
|
|
|
|
|
| |
This is because I want to add another remote execution related tool, the remote_client, which will use the Remote Execution API to fetch blobs from a remote cache. I will use this tool as part of end-to-end tests for remote execution.
TESTED=remote integration tests, presubmit
RELNOTES: None
PiperOrigin-RevId: 177995895
|
|
|
|
|
|
|
| |
See https://github.com/bazelbuild/bazel/issues/4230.
Change-Id: Ia0125d76eb47226ad8e09829e559d636f064b369
RELNOTES: None
|
|
|
|
|
|
|
|
|
| |
This will allow us to write a bazel integration test for --android_aapt=aapt2.
Necessary for https://github.com/bazelbuild/bazel/issues/4103.
RELNOTES: None
PiperOrigin-RevId: 177980382
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 177965330
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 177965009
|
|
|
|
|
|
|
|
|
| |
...through the corresponding environment variables. In this
way, more than one documentation version can be served, e.g.,
to simplify comparing.
Change-Id: I4ae069a4a48f12e9bd48210ee3bd22299149f59d
PiperOrigin-RevId: 177959891
|
|
|
|
|
|
|
|
|
|
|
| |
JavaSkylarkApiProvider will be deprecated soon and replaced by JavaInfo.
Methods exposed:
getGenJarsProvider()
Made changed in all relevant Java family rules, to build JavaGenJarsProvider provider and assign to JavaInfo
RELNOTES:none
PiperOrigin-RevId: 177950965
|
|
|
|
|
|
|
|
|
| |
This is arguably more correct, since output files don't have any tags, therefore you cannot exclude them by specifying tags to exclude.
Fixes #4012.
RELNOTES: None.
PiperOrigin-RevId: 177950851
|
|
|
|
|
|
|
| |
don't serve any apparent purpose. The reason for these changes is that we're switching from checked-in BUILD files to generated BUILD files, and there may be small differences between these files.
RELNOTES: None
PiperOrigin-RevId: 177949511
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel's fallback action config for PGO optimization uses Google-internal
compiler flags. Here, we provide a 'fdo_optimize' feature without these internal
flags, so --fdo_optimize can work out of the box.
This fixes https://github.com/bazelbuild/bazel/issues/1171.
Change-Id: I1d40eb72211e7c5bea213de7d2c237ac2877b3a1
PiperOrigin-RevId: 177947264
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Baseline: cff0dc94f6a8e16492adf54c88d0b26abe903d4c
Cherry picks:
+ 8a49b156c4edf710e3e1e0acfde5a8d27cc3a086:
Fix ImportError on tools.android for junction_lib
+ 275ae45b1228bdd0f912c4fbd634b29ba4180383:
Automated rollback of commit
4869c4e17d5b1410070a1570f3244148d8f97b5d.
+ d0bf589f2716b3d139c210930371a684c6e158eb:
Add a random number to action temp dir
+ 9738f35abddb7ef7a7ef314b5d2a52a3be1b830a:
CcProtoLibrary: Don't add dynamic librarys to filesToBuild on
Windows
+ 0d6ff477099fdf6c8c1c7d4e2104f9184afe0a2b:
Automated rollback of commit
0ebb3e54fc890946ae6b3d059ecbd50e4b5ec840.
+ 49008a3c90e65bc4abf5292af823a931b8f4e096:
Avoid NPEs when providers are not found in JavaInfo.
+ f499ddc6cf2f1dc5610e04f6ab42c1d11bad7b80:
Added missed imports.
0.8.1rc3
Cherry-picked https://github.com/bazelbuild/bazel/commit/49008a3c90e65bc4abf5292af823a931b8f4e096.
Additional change to fix the missing imports.
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 177944402
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Context: java_import or other custom rules (genrules or Skylark) do not propagate coverage information. Coverage metadata is retrieved from the compilation information and it is passed around through providers as Artifact(s). The problem with the current implementation is that there is no way of retrieving instrumentation metadata from arbitrary jars provided by java_import or other custom rules.
--experimental_java_coverage solves the issue presented above ONLY for the java rules (has no effect for android/[]/etc).
Implementation details:
* For each build jar create a .txt file containing the relative path of each Java file. This file is included in the build jar. It is used for recreating the correct path for each covered file when included in the coverage report.
* java_binary/java_test will set 3 environment variables:
1) JACOCO_METADATA_JAR - in experimental mode will be a txt file containing all the jars considered for collecting coverage (JacocoCoverageRunner filters out the ones that don't have .uninstrumented.class files). In non-experimental mode will be a jar containing all the instrumented class files.
2) JACOCO_MAIN_CLASS - The main class to be called for the current coverage run. Previously this information was embedded in the JACOCO_METADATA_JAR's manifest.
3) JACOCO_JAVA_RUNFILES
RELNOTES: --experimental_java_coverage is available for testing.
PiperOrigin-RevId: 177941471
|
|
|
|
|
| |
RELNOTES: The --remote_rest_cache flag now respects --remote_timeout.
PiperOrigin-RevId: 177926523
|
|
|
|
|
| |
TESTED=ran with SHA1 and SHA256
PiperOrigin-RevId: 177925963
|
|
|
|
|
|
|
|
| |
Fixes #3573
Closes #3574.
PiperOrigin-RevId: 177925152
|
|
|
|
|
|
|
| |
Part of #4128.
Change-Id: Id822d3ae6f8daf7c92a75bd8bd28590d4f625845
PiperOrigin-RevId: 177905460
|
|
|
|
|
|
| |
RELNOTES:None.
PiperOrigin-RevId: 177875613
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few of the InferredType's fields were being static imported, but not all of them, and the use of the statically imported fields was inconsistent. Statically importing the inner class causes strange errors when building desugar in the Android platform build with OpenJDK8, but not OpenJDK9:
external/desugar/java/com/google/devtools/build/android/desugar/BytecodeTypeInference.java:1015: error: cannot find symbol
@AutoValue
^
symbol: class AutoValue
location: class BytecodeTypeInference
1 error
Remove the static imports to make the build work and to make the usage consistent.
RELNOTES:None.
PiperOrigin-RevId: 177875501
|
|
|
|
|
| |
RELNOTES: The --host_platform and --platform flags are no longer experimental.
PiperOrigin-RevId: 177863761
|
|
|
|
|
|
|
|
|
| |
bundle_loader attribute
Prior to this change, apple_binary relied on bundle_loader targets (which are themselves apple_binary) to propagate an unwrapped ObjcProvider. That is deprecated, is disabled by --noexperimental_objc_provider_from_linked, and will be killed off shortly.
RELNOTES: None.
PiperOrigin-RevId: 177862573
|
|
|
|
|
| |
RELNOTES: Document startup option --host_javabase
PiperOrigin-RevId: 177849387
|
|
|
|
|
|
|
| |
Commit d926bc40260549b997a6a5a1e82d9e7999dbb65e fixed a bug (#4206, #4208) in
the third_party python gflags pseudo-package but added excessive runtime
warnings (see #4212). Using the python PEP 328 (absolute import) implementation
eliminates these warnings while properly addressing the original bug.
|
|
|
|
|
|
|
|
|
| |
This does not provide any meaningful API to interact with ObjcProtoProvider from a skylark context -- it simply allows ObjcProtoProvider to be passed between skylark API calls as an opaque object.
This helps facilitate exposure of an Apple Linking API to Skylark which will take place in future changes.
RELNOTES: None.
PiperOrigin-RevId: 177844029
|
|
|
|
|
|
|
|
|
|
| |
Basically a refactor of https://github.com/bazelbuild/bazel/pull/2053, which separated the concepts of async and expunge but kept them intertwined at the option level. This was confusing to a number of users. The standard interface is to use one of --expunge, --async, or --expunge_async. --clean_style was more verbose and added no value, so can be removed.
The contents of actuallyClean() could use some ... actual cleaning. This CL just changes the options, removing some of the artificial option-related complexity.
RELNOTES[INC]: --clean_style is no longer an option.
PiperOrigin-RevId: 177843049
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, SymlinkTreeAction no longer needs to accept artifacts
as an input. --experimental_enable_runfiles now immediately reports an
error on Windows.
This mostly unwinds e4974e4cc6aeb437d36b3b36eb20142b7120fb16
("Separate runfiles middlemen into two layers") and
41f4456ac2348bef66739194853a1ddadcbb887e ("Make runfiles tree creation
on Windows depend on the artifacts of the actual runfiles."). See
https://groups.google.com/d/msg/bazel-dev/btOAgxv434g/bDhTOOePAgAJ.
Change-Id: Iac3308669bfc07abfd1c91445922269d8fdc2a26
PiperOrigin-RevId: 177837504
|
|
|
|
|
|
|
|
| |
Explicitly emphasize that the distribution archive is architecture independent. In
particular, users do not have to look for their architecture. This has led to confusions.
Change-Id: If7c75fcde4ec85d5670eb2c893ffcb4be65e3c0c
PiperOrigin-RevId: 177835486
|
|
|
|
|
|
|
| |
Previously, they were in the Error checking options section, which doesn't seem correct.
Change-Id: I1306da91cff01157963d56db267188bda7d57d4f
PiperOrigin-RevId: 177835450
|
|
|
|
|
|
|
|
|
| |
- Replace the existing Retrier with Retrier2.
- Rename Retrier2 to Retrier and remove the old Retrier + RetryException
class.
RELNOTES: None.
PiperOrigin-RevId: 177835070
|
|
|
|
|
|
|
|
| |
Fixes #4202
Closes #4214.
PiperOrigin-RevId: 177829932
|
|
|
|
|
|
|
|
|
|
| |
User might have Visual C++ Build Tools and JDK installed at non-default location, but they are still usable for bootstrapping.
PS: I used Visual C++ 2017 15.3 for bootstrapping, there is a nice 1.5MB size reduction in final `bazel.exe` compared with `bazel-0.7.0-without-jdk-windows-x86_64.exe`.
Closes #3943.
PiperOrigin-RevId: 177815687
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/4028
Closes #4029.
PiperOrigin-RevId: 177813419
|
|
|
|
|
|
|
| |
Fixes #4056.
Change-Id: Ia7425c2146f15e9293605ee3da53007805e82275
PiperOrigin-RevId: 177813070
|
|
|
|
|
|
|
|
| |
the CppConfiguration Skylark API to migrate to platforms and toolchains.
For more details on toolchains, please see https://docs.google.com/document/d/1-G-VPRLEj9VyfC6VrQBiR8To-dZjnBSQS66Y4nargGM/edit#heading=h.al54v2ddwqzv
PiperOrigin-RevId: 177811908
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JavaSkylarkApiProvider will be deprecated soon and replaced by JavaInfo.
Methods exposed:
NestedSet<Artifact> getTransitiveSourceJars()
NestedSet<Artifact> getTransitiveRuntimeDeps()
NestedSet<Artifact> getTransitiveDeps()
Also created helped method to eliminate all duplication code and refactored some methods with is.
RELNOTES:none
PiperOrigin-RevId: 177804645
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stub template now looks for the python binary relative to the
modules if a relative path was provided. This correctly finds it
inside the runfiles folder both when the py_binary is the output,
and when the py_binary is called by another binary
(ie is data for it).
We also now add the binary and dependencies to the runfiles when it
is used as data so python is accesible.
Change-Id: I3bf6ff17265e72d964614ad66af22933c89f853d
PiperOrigin-RevId: 177803641
|
|
|
|
|
|
|
|
| |
Resolves issue https://github.com/bazelbuild/bazel/issues/4146
Closes #4147.
PiperOrigin-RevId: 177803394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a roll-forward of https://github.com/bazelbuild/bazel/commit/e8d32b7c922f65539b74357711d5ad6b70934115, which broke some genrules, but without
some cleanup changes which I'm submitting separately, and with a fix for the
bug.
The problem was that I switched from withExecLocations(labels) to
withExecLocations(); the original code was in CommandHelper, and the new
code in GenRuleBase, so this was not obvious.
Also, we didn't have test coverage for this case - note that the specified
labels are _added_ to the default map of labels, rather than replacing the
default map of labels. This only matters if the dependent rule provides a
GenRuleSourcesProvider, which only a single (Google-internal) rule does.
PiperOrigin-RevId: 177802902
|
|
|
|
|
|
|
| |
RELNOTES:
First argument of 'load' must be a label. Path syntax is removed.
(label should start with '//' or ':').
PiperOrigin-RevId: 177802628
|
|
|
|
|
|
|
| |
source for docs.bazel.build (because those subdomains don't resolve here; they resolve to bazel.build, which has the redirects for them)
RELNOTES: Remove redirects for domains be.bazel.build and cr.bazel.build from the source for docs.bazel.build (because those subdomains don't resolve here; they resolve to bazel.build, which has the redirects for them)
PiperOrigin-RevId: 177787458
|
|
|
|
|
|
|
|
|
|
| |
The same information is accessible as JavaRuntimeInfo.java_executable_exec_path. In order to access that, add an implicit attribute that depends on @bazel_tools//tools/jdk:current_java_runtime, then do
ctx.attr._java_runtime[java_common.JavaRuntimeInfo].java_executable_exec_path .
RELNOTES[INC]: The path to the JVM executable is not accessible anymore as ctx.{fragments,host_fragments}.jvm.java_executable. Use JavaRuntimeInfo.java_executable_exec_path instead.
PiperOrigin-RevId: 177786910
|