aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android/AndroidResourceMergingActionBuilder.java
Commit message (Collapse)AuthorAge
* Add more type safety to CustomCommandLine.Gravatar tomlu2017-08-16
| | | | | | | | | | | | Allowing add(Object) is too loose and can easily lead to programmer mistakes. Because of type erasure, we can't use the same overload name for (eg.) add(NestedSet<String>) and add(NestedSet<Artifact>). The API is overhauled to use the same terms everywhere, eg. "add", "addPaths", "addExecPaths". This is similar to how it used to be a few CLs ago. The API is overhauled to make sure it's consistent for all types. While tedious, the facade methods immediately dispatch to internal helpers, so implementation wise it's not too heavy. While large, this CL is almost entirely an automated refactor. PiperOrigin-RevId: 165358287
* Add @CompileTimeConstant annotations to CustomCommandLine.Gravatar tomlu2017-08-16
| | | | | | | | | This enforces certain memory-efficient patterns. For deliberate use of dynamic strings, explicitly named overloads are introduced, with javadoc that guides the programmer into making the right choice. This CL is a memory no-op on benchmarks, but it tries to prevent backslide by making sure programmers make conscious choices when they construct their command lines. RELNOTES: None PiperOrigin-RevId: 165185997
* Inline @Deprecated methods in CustomCommandLine.Gravatar tomlu2017-08-11
| | | | | | | | | Apart from updating CustomCommandLineTest this CL is entirely automated. We also sneak in a rename of addFormat -> addFormatted. RELNOTES: None PiperOrigin-RevId: 164870140
* Automated rollback of commit f7f1a8f756f33f86b1bdc5023d5052117b62523e.Gravatar laszlocsomor2017-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Updated to avoid https://github.com/bazelbuild/bazel/issues/3501 This is a rollback of a rollback, with additional modifications to BazelConfiguration.java to fix https://github.com/bazelbuild/bazel/issues/3501, the issue that was the reason we rolled back the original change. The additional updates serve to propagate the client's TMP and TEMP envvars to the action, which is a short-term solution to allow actions have a TMP/TEMP envvar on Windows. They need at least one of those to create temp directories. The long-term solution is to set a value for TMP or TEMP in the executor just before executing the actions, so the TMP/TEMP would not be part of the action key. All of this only affects Bazel on Windows. *** Original change description *** Automated rollback of commit 0abf5fa2d64c76def5a8fa0f960b73ce0566af4d. *** Reason for rollback *** Breaks Bazel CI (https://github.com/bazelbuild/bazel/issues/3501) *** Original change description *** Android BusyBox: actions use the default shell env SpawnActions that run the Android BusyBox now use the default shell environment. This has the following benefits: - Bazel propagates the PATH, TMPDIR envvars to the action - Bazel propagates the --action_env envvars to the action This allows the Bazel client to pass --action_env=TMP or --action_env=TEMP (whichever of the envvars is defined) to the server, so the BusyBox actions will have TMP/TEMP set (to the same value as the clientenv), so they can create temp directories using java.nio.file.Files.createTempDirectory. This method seems to be calling the GetTempPath WinAPI function, which needs the TMP or TEMP envvar, otherwise it falls back to returning c:\windows which is non-writable. There's one drawback of using the default shell environment, although @ulfjack is working on it: - PATH is now also part of the action's cache key. However in a single-machine environment (no remote execution) and assuming PATH isn't likely to change between builds, this probably doesn't poision the action cache in practice. This change is a short-term solution. Propagating the client env's TMP/TEMP means we make that part of the action's cache key. The ideal long-term solution will be to not propagate this envvar, and instead let the execution strategy set it to some client-env-independent value. See https://github.com/bazelbuild/bazel/issues/3264 Change-Id: I756a4203b5d86c881bc36cc089e35cde0d419914 RELNOTES: none PiperOrigin-RevId: 164696600
* Windows, AndroidBusyBox: always use params filesGravatar laszlocsomor2017-08-09
| | | | | | | | | | | | | | | On Windows, Bazel will always use params files for some BusyBox tools, because some flags of these tools expect values with special characters in them. We need this change so Bazel can safely pass such flags to the BusyBox on Windows. See https://github.com/bazelbuild/bazel/issues/3264 RELNOTES: none PiperOrigin-RevId: 164582899
* Automated rollback of commit 0abf5fa2d64c76def5a8fa0f960b73ce0566af4d.Gravatar laszlocsomor2017-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks Bazel CI (https://github.com/bazelbuild/bazel/issues/3501) *** Original change description *** Android BusyBox: actions use the default shell env SpawnActions that run the Android BusyBox now use the default shell environment. This has the following benefits: - Bazel propagates the PATH, TMPDIR envvars to the action - Bazel propagates the --action_env envvars to the action This allows the Bazel client to pass --action_env=TMP or --action_env=TEMP (whichever of the envvars is defined) to the server, so the BusyBox actions will have TMP/TEMP set... *** PiperOrigin-RevId: 164126020
* Android BusyBox: actions use the default shell envGravatar Laszlo Csomor2017-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SpawnActions that run the Android BusyBox now use the default shell environment. This has the following benefits: - Bazel propagates the PATH, TMPDIR envvars to the action - Bazel propagates the --action_env envvars to the action This allows the Bazel client to pass --action_env=TMP or --action_env=TEMP (whichever of the envvars is defined) to the server, so the BusyBox actions will have TMP/TEMP set (to the same value as the clientenv), so they can create temp directories using java.nio.file.Files.createTempDirectory. This method seems to be calling the GetTempPath WinAPI function, which needs the TMP or TEMP envvar, otherwise it falls back to returning c:\windows which is non-writable. There's one drawback of using the default shell environment, although @ulfjack is working on it: - PATH is now also part of the action's cache key. However in a single-machine environment (no remote execution) and assuming PATH isn't likely to change between builds, this probably doesn't poision the action cache in practice. This change is a short-term solution. Propagating the client env's TMP/TEMP means we make that part of the action's cache key. The ideal long-term solution will be to not propagate this envvar, and instead let the execution strategy set it to some client-env-independent value. See https://github.com/bazelbuild/bazel/issues/3264 Change-Id: I756a4203b5d86c881bc36cc089e35cde0d419914 PiperOrigin-RevId: 164114502
* Compute progress message lazily in spawn action.Gravatar tomlu2017-08-03
| | | | | | | | | | 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
* Add flag to turn Android resource merge conflicts from warnings into errorsGravatar Googler2017-07-14
| | | | | RELNOTES: none PiperOrigin-RevId: 161831232
* Enable aapt2 support in library actions.Gravatar corysmith2017-06-29
| | | | | RELNOTES: None PiperOrigin-RevId: 160445869
* Rollback of commit bd40871283a54268945dcb0c47c0326645ffda18.Gravatar Googler2017-03-24
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Rollback of commit a58f245a4b40c0ef961b1f30d96b16a9349711c3.Gravatar Tobias Werth2017-03-20
| | | | | | | | | | | | | | | *** 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
* Move library R generation to a separate action, ensuring the merging happensGravatar Googler2017-03-20
| | | | | | | | off the java critical path. -- PiperOrigin-RevId: 150460041 MOS_MIGRATED_REVID=150460041
* Make Android data binding work with ↵Gravatar Greg Estren2017-02-17
| | | | | | | | | | | | | | | | | | | | | --experimental_use_parallel_android_resource_processing. Without that flag, data binding already works via hooks in ApplicationManifest and AndroidResourceProcessingAction. The flag replaces AndroidResourceProcessingAction with three smaller processors: AndroidResourceParsingAction, AndroidResourceMergingAction, and AndroidResourceValidatorAction. So this change hooks the same logic into AndroidResourceMergingAction (at the equivalent place where data binding applies in the other pipeline). We could alternatively hook this into AndroidResourceValidatorAction (i.e. anywhere after resource merging completes and before aapt starts). But doing that would block Java compilation on aapt finishing, which the whole point of the flag is to unblock. -- PiperOrigin-RevId: 147770236 MOS_MIGRATED_REVID=147770236
* Rollback of commit 602a98cbebeff2ba1c2d8605a9552b2c8f5622ae.Gravatar Googler2017-02-09
| | | | | | | | | | | | | | | | *** Reason for rollback *** Rolling forward with fixes for the incremental tool. *** Original change description *** Automated [] rollback of commit d11d510c571b10787856395709f9ad945ca70bb2. *** Reason for rollback *** -- PiperOrigin-RevId: 146940409 MOS_MIGRATED_REVID=146940409
* Rollback of commit d11d510c571b10787856395709f9ad945ca70bb2.Gravatar Alex Humesky2017-02-08
| | | | | | | | *** Reason for rollback *** -- PiperOrigin-RevId: 146820790 MOS_MIGRATED_REVID=146820790
* Move all the resource processing tools into a "busybox".Gravatar Googler2017-02-08
| | | | | | | | | This makes the code simpler as well as reducing the number of targets to build. It also makes testing and profiling different action strategies vastly easier. -- PiperOrigin-RevId: 146812659 MOS_MIGRATED_REVID=146812659
* Add parameter files to the android resource processing.Gravatar Googler2017-01-26
| | | | | | -- PiperOrigin-RevId: 145686107 MOS_MIGRATED_REVID=145686107
* Refactor ResourceContainer: make top level and use AutoValue Builder support.Gravatar Michael Staib2017-01-04
| | | | | | | | | | | | | | | | This merges the AndroidResourceContainerBuilder (which it's not even clear is related to the nested ResourceContainer!) into the newly generated ResourceContainer.Builder. It also seemed ridiculous for ResourceContainer to get so large and still be subordinate to AndroidResourcesProvider, especially when it's getting passed around in a lot of other places (look how many imports needed fixing!). This CL makes it its own top level class. This allows for easy modification of an existing instance: call toBuilder on it, set the properties you want set, and then call build. -- PiperOrigin-RevId: 143574468 MOS_MIGRATED_REVID=143574468
* Spam lib/rules/android with @AutoValue. Mostly created byGravatar Googler2016-09-01
| | | | | -- MOS_MIGRATED_REVID=131832497
* Hook up split-up resource processing tools for android_libraryGravatar Googler2016-08-30
| | | | | | | | | | Behind a flag. Flow is: parse -> merge -> validate \--> compile With fewer deps across the merge steps. -- MOS_MIGRATED_REVID=131634115
* Add a lightweight resource merge action.Gravatar Googler2016-08-30
Part 2 of the 3 new proposed android_library res processing actions. The primary and deps are all assumed to be parsed+summarized in a protobuf. Represent that with a new class (similar to DependencyAndroidData but w/out R.txt). Avoid having "manifest" artifacts as deps input, and instead use "label", since that is only used in a warning. DepAD still uses the manifest for #asSymbolFileProvider, so we keep it there. Move loading the primary out of the merge function so that we can share the merge function with this style of primary data, and the existing style of of primary data (UnvalidatedAndroidData). This produces an R class.jar and a zip file to pass along to a future validation action. Images are stubbed out since they are irrelevant to the validation action. -- MOS_MIGRATED_REVID=131604421
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 04:01:22 +0000