| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aar_resources_extractor now supports long paths
on Windows.
If the script needs to extract a file from the
AAR where the destination path is too long, the
script will:
1. create a temporary junction under a short path,
pointing to the destination directory (which
has a long path)
2. extract the file under the junction
3. delete the junction and the temp directory
See https://github.com/bazelbuild/bazel/issues/3659
Change-Id: Ie85665b360a6514afaac546aaec8869224fe9d06
PiperOrigin-RevId: 167545085
|
|
|
|
|
|
|
|
|
| |
To do this, add a new tool that is used instead of zipper to get the resources out of the AAR. This tool creates res/values/empty.xml if there are no resources in the AAR.
Also, some general cleaning of the code.
RELNOTES: None
PiperOrigin-RevId: 166768607
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change forces use of CustomCommandLine.Builder, which has a richer interface for constructing memory-efficient command lines. It will also permit surveying the code base for inefficient patterns using an IDE.
This change was done by hand and split using Rosie to assist with rollbacks in case of bugs. Reviewers, please pay particular attention to:
* Each all to addInputArgument/addOutputArgument should come with a corresponding matching pair to SpawnAction.Builder#addInput and CustomCommandLine.Builder#addExecPath (eg.).
* The commandLine must be set on the SpawnAction using SpawnAction.Builder#setCommandLine.
Note that most calls to addPrefixed("arg=", val) should be more idiomatically expressed as add("arg", val), but this involves changing tests and making sure that the command line tools can accept the format.
PiperOrigin-RevId: 166098373
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165910455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
android_libraries can now be used in the resources attribute. However, if these
libraries contain non-resource information, it won't get picked up. To prevent
unexpected behavior, fail if such libraries are used as resources.
Adding a temporary boolean to AndroidResourcesProvider seems to be the most
straightforward way of doing this. The alternative, having the consuming target
check all relevant providers for non-resource information, would be much
messier.
RELNOTES: None
PiperOrigin-RevId: 165703578
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164446955
|
|
|
|
|
|
|
|
|
| |
Add SpawnAction.Builder#setProgressMessageNonLazy for dynamic strings. This should help guide users to the right method.
This also helped find a few methods I'd missed previously that could use a constant-string version.
RELNOTES: None
PiperOrigin-RevId: 164150264
|
|
|
|
|
|
|
|
|
|
| |
Consumers using spawn action builder now have access to handy overloads that behind the scene do a lazy String.format. In 95% of cases progress messages are expressible as 0, 1, or 2 argument String.formats.
This saves memory because the format string is constant and shared between all actions, and the captured subjects are usually live on the heap anyway (eg. labels).
Skylark still computes its progress messages eagerly. If we want similar savings there I'd have to follow up with a Skylark proposal.
PiperOrigin-RevId: 164068816
|
|
|
|
|
|
|
| |
This is so that we can eventually route the information it now contains through JavaRuntimeProvider.
RELNOTES: None.
PiperOrigin-RevId: 161196809
|
|
|
|
|
|
|
|
| |
* Split the aar, library and binary packWith calls.
* Remove unused argument from the new binary and library packWith calls.
RELNOTES: None
PiperOrigin-RevId: 160414867
|
|
|
|
|
|
|
| |
Without this, aar_import targets will not have java attribute in skylark, therefore not able to generate any ide info by intellij_info_aspect in intellij_info.bzl.
RELNOTES: None.
PiperOrigin-RevId: 160146803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rolling forward with the correct changes to the AndroidResourceMergingAction. Tested manually.
*** Original change description ***
Automated [] rollback of commit a58f245a4b40c0ef961b1f30d96b16a9349711c3.
*** Reason for rollback ***
broke over 100k targets, in the depot, see []
*** Original change description ***
Move library R generation to a separate action, ensuring the merging happens
off the java critical path.
--
PiperOrigin-RevId: 151087737
MOS_MIGRATED_REVID=151087737
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
broke over 100k targets, in the depot, see []
*** Original change description ***
Move library R generation to a separate action, ensuring the merging happens
off the java critical path.
--
PiperOrigin-RevId: 150602545
MOS_MIGRATED_REVID=150602545
|
|
|
|
|
|
|
|
| |
off the java critical path.
--
PiperOrigin-RevId: 150460041
MOS_MIGRATED_REVID=150460041
|
|
|
|
|
|
|
|
|
|
|
| |
Having a correlation between an output jar and a source jar is not enough.
There may be situations when an output jar is generated from more source jars,
not just one. We need this flexibility especially in Skylark for the java
sandwich, when the user can compile multiple source jars.
--
PiperOrigin-RevId: 149510534
MOS_MIGRATED_REVID=149510534
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/issues/2500
--
PiperOrigin-RevId: 147089163
MOS_MIGRATED_REVID=147089163
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 144741831
MOS_MIGRATED_REVID=144741831
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rollforward with fix for AarImportTest. The test failed previously due to a difference in the configuration because getConfiguredTarget("//a:bar") does not invoke the android split transition, so the artifact paths did not exactly match.
*** Original change description ***
Automated [] rollback of commit 7fc35ae6890f4130b4d99a6c5007dcee91c5a8cc.
*** Reason for rollback ***
Breaks //src/test/java/com/google/devtools/build/lib:bazel-rules-tests
http://ci.bazel.io/view/Dashboard/job/bazel-tests/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/lastCompletedBuild/console
*** Original change description ***
aar_import provides JavaCompilationArgsProvider for DexArchiveAspect.
--
PiperOrigin-RevId: 144370584
MOS_MIGRATED_REVID=144370584
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks //src/test/java/com/google/devtools/build/lib:bazel-rules-tests
http://ci.bazel.io/view/Dashboard/job/bazel-tests/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/lastCompletedBuild/console
*** Original change description ***
aar_import provides JavaCompilationArgsProvider for DexArchiveAspect.
--
PiperOrigin-RevId: 144316524
MOS_MIGRATED_REVID=144316524
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 144258810
MOS_MIGRATED_REVID=144258810
|
|
|
|
|
|
|
|
|
|
| |
Previously, the FilesToBuild included the unprocessed resources. This meant that
some bugs did not manifest themselves by building just the aar_import but only
showed up if the aar_import was depended on by an android_library.
--
PiperOrigin-RevId: 141068502
MOS_MIGRATED_REVID=141068502
|
|
|
|
|
|
|
|
| |
AAR embedded JARs contain some compressed files (.class) and some
non-compressed files (Java resources).
--
MOS_MIGRATED_REVID=139222696
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=139205671
|
|
|
|
|
|
|
|
|
| |
This was an oversight on my part in the original implementation. As one
example, the Firebase AAR libraries contain AndroidManifest.xml's
with ${applicationId} and Google Play Services contain <meta-data> tags.
--
MOS_MIGRATED_REVID=138198047
|
|
|
|
|
|
|
| |
See https://github.com/bazelbuild/bazel/issues/1935
--
MOS_MIGRATED_REVID=137202533
|
|
|
|
|
|
|
| |
The libs that are extracted are dependent on the CPU from the Android split transition. This is set either from --fat_apk_cpu or --android_cpu if fat_apk_cpu is empty.
--
MOS_MIGRATED_REVID=137188695
|
|
Also moves AAR-specific tools from tools/zip into tools/android and renames embedded_jar_extractor to aar_embedded_jars_extractor because in a future change it will extract classes.jar and libs/*.jar.
--
MOS_MIGRATED_REVID=136099324
|