aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android/AndroidResourceMergingActionBuilder.java
Commit message (Collapse)AuthorAge
* Remove CompiledMergeableAndroidDataGravatar asteinb2018-08-08
| | | | | | | | This was also just shared between ParsedAndroidResources and the now defunct ResourceContainer RELNOTES: none PiperOrigin-RevId: 207907140
* Remove ResourceContainerGravatar asteinb2018-08-08
| | | | | | | | | ValidatedAndroidResources is now the only implementation of ValidatedAndroidData, so we can also clean up some code. (The actual interface will be cleaned up in the next few changes.) RELNOTES: none PiperOrigin-RevId: 207891778
* @AutoCodec stray usage of AndroidDataConverter. It should always be a static ↵Gravatar janakr2018-06-13
| | | | | | | | | | constant. This allows us to continue using lambdas in its definition. This is a partial rollback of https://github.com/bazelbuild/bazel/commit/ed1e7594b23100f89755491f36e46886b4a51c8d, since the work done to class-ify things there is unnecessary once every instance is @AutoCodec-ed. PiperOrigin-RevId: 200504678
* Automated rollback of commit 372fbc2f016157b0331f83a20edad10d4b4cf9f7.Gravatar asteinb2018-05-25
| | | | | | | | | | | | | *** Reason for rollback *** Roll forward with fix: I was assuming that R.txt and symbols files are always set, but they can be null in some cases (especially in the old data processing pipeline). Properly handle them here. RELNOTES: none PiperOrigin-RevId: 198075743
* Automated rollback of commit 9d5c323a6e66842cfeb98462cf949dee58710fb8.Gravatar plf2018-05-25
| | | | | | | | *** Reason for rollback *** Crashes lots of targets in nightly blaze-2018.05.24-1: PiperOrigin-RevId: 198049395
* Move resource busybox actions to BusyBoxActionBuilder and AndroidDataContextGravatar asteinb2018-05-23
| | | | | | | | | | | | | | | | | | | | | | | BusyBoxActionBuilder makes much cleaner action builders while making it harder to do Bad Things (like collapsing NestedSets in analysis, or adding an artifact to one of the command line and the inputs but not both). Also: - In merging, simplify the code somewhat by removing unneeded conditionals - for example, the parsed merging action will always be built given the current code. - In the few builders where we aren't doing so already, parameter files should always be shell quoted and always be used when the OS is Windows. The BusyBox should always support the former and require the latter (although sufficiently large inputs may have masked this by triggering parameter files in Windows anyway). - In the builder for linking (within validation), no longer collapse the NestedSet of transitiveCompiledSymbols when adding them to the inputs. Using the new BusyBoxActionBuilder code, trying to do this would throw an IllegalStateException. RELNOTES: none PiperOrigin-RevId: 197728382
* Setup for wiring up decoupled data processing in top-level targetsGravatar asteinb2018-04-18
| | | | | | | | | | | | - Expose manifest merging logic from ApplicationManifest - Use it to reimplement manifest merging in new AndroidManifest class - Track merged resources zip in ResourceContainer - we shouldn't be forced to use hacks to get it - Clean up return type of ProcessedAndroidData.generateRClass - a ResourceApk is the general type used to wrap fully processed data. RELNOTES: none PiperOrigin-RevId: 193367162
* Independently merge assetsGravatar asteinb2018-04-17
| | | | | | | | | | Merges assets using the newly created action. Also, add BusyBoxActionBuilder to collect common boilerplate for spawning an action that invokes the Android busybox. RELNOTES: none PiperOrigin-RevId: 193192621
* Resource-only merge actionGravatar asteinb2018-04-13
| | | | | | | | | | | | | | | | | | | Create wrapper for merged resources, and methods to make it from parsed resources. Currently just reuse the ResourceDependencies class to provide resource dependencies; we could create an interface and another class, but this class is good enough (and will be resource-specific once we finish decoupling assets, resources, and manifests). Note that, like the previous parse action, merging sometimes has a dependency on the stamped manifest, so resources and manifests will only be mostly decoupled. Also, make the merge action not require an output manifest for cases like this. RELNOTES: none PiperOrigin-RevId: 192805891
* Make resource merging action builder able to take just resourcesGravatar asteinb2018-04-12
| | | | | | | | | | | | In the next review, this will be used to merge resources (without assets) To support this, we need to pass around a stamped manifest with the parsed resources (since manifests cannot be decoupled fully from resource processing - aar_import means that stamped manifests are the only guaranteed way to get package information). RELNOTES: none PiperOrigin-RevId: 192649272
* Automated rollback of commit 9bfbefc13f2b6ae9a86fd46a8470e3b4cd8efd1a.Gravatar asteinb2018-04-02
| | | | | | | | | | | | | | *** Reason for rollback *** Roll forward with fix and test - turns out I didn't distinguish properly between list and item seperators. *** Original change description *** Rollback "Allow Merge action to take an interface as primary, not just ResourceContainer", as it breaks some android rule integration tests. RELNOTES: none PiperOrigin-RevId: 191322706
* Rollback "Allow Merge action to take an interface as primary, not just ↵Gravatar cparsons2018-04-02
| | | | | | | ResourceContainer", as it breaks some android rule integration tests. RELNOTES: none PiperOrigin-RevId: 191304264
* Allow Merge action to take an interface as primary, not just ResourceContainerGravatar asteinb2018-03-29
| | | | | | | | | | | | | | In future reviews, we will use this to be able to pass assets and resources individually. Introduce replacement for ResourceContainerConverter that can handle generics and should be about as flexible. To support that replacement, slightly improve how CustomCommandLine handles generics. RELNOTES: none PiperOrigin-RevId: 190970298
* Have the Android R class generators add the target label to the class jar.Gravatar tomlu2018-03-20
| | | | | | | This re-enables support for add_deps. RELNOTES: None PiperOrigin-RevId: 189737607
* Move CommandLine, CommandLineItem, and ParamFileInfo from ↵Gravatar tomlu2018-02-15
| | | | | | | | | lib.analysis.actions -> lib.actions. These are fundamental types that want to sit alongside types like Spawn. RELNOTES: None PiperOrigin-RevId: 185887971
* Allow CustomCommandLine's mapFn to expand each object into multiple items.Gravatar tomlu2018-02-01
| | | | | | This is needed to migrate JavaCompileAction away from CustomMultiArgv. PiperOrigin-RevId: 184136486
* Improve safety of NestedSetFingerprintCache by detecting multiple instances ↵Gravatar tomlu2018-01-31
| | | | | | | | | | | | of the same mapFn class. This code tries to add protection against the user creating new mapFn instances per-rule. This would cause the nested set cache to be computed per-rule instead of shared across rule instances, causing memory bloat and slowdowns. Since this can only happen in native code, we can get away with detecting this and crashing blaze. I think this is a better choice than silently allowing it / falling back to slow computations. The user can override this behaviour by inheriting from CommandLineItem.CapturingMapFn, in which case the user is explicitly saying they assume responsibility for the number of instances of the mapFn the application will use. PiperOrigin-RevId: 184061642
* Add CommandLineItem interface.Gravatar tomlu2018-01-25
| | | | | | | | This interface makes it clearer in the type system exactly how items that go into a CustomCommandLine are turned into strings. It is a preparatory change to allow command line fingerprints to be more cheaply calculated, but it is valuable in itself from a code quality standpoint. PiperOrigin-RevId: 183274022
* Automatic formatting cleanup of Android *.java files.Gravatar jingwen2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179425421
* Add experimental flag to skip the parsing action if using aapt2.Gravatar Googler2017-11-15
| | | | | RELNOTES: none PiperOrigin-RevId: 175866310
* Fix changes that broke resource filtering, and document related confusionGravatar Googler2017-10-23
| | | | | | | | | | | | | | | | | | | | | | | | Recent changes: 1) Started passing all resources to processors, ignoring the filtered ResourceContainers, and 2) Started loading an unfiltered LocalResourceContainer into binary resource processing, in addition to the filtered container. Fix both of these. To fix the former, we need to split the misleadingly-named 'transitiveResourceRoots' (actually transitive resource and assets artifacts) into transitive resources and assets. Update resource filtering tests to catch bugs like these. Also, rename getters for resource containers to make clear that they are not getters for resources. Finally, document some weirdness and partially-completed migrations encountered as part of investigating these issues, and add appropriate TODOs and deprecation. RELNOTES: None PiperOrigin-RevId: 172929936
* Migrate ResourceProcessorBusyBox Android actions to using SHELL_QUOTED param ↵Gravatar apell2017-10-18
| | | | | | | files. RELNOTES: None. PiperOrigin-RevId: 172485548
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* Support multiple command lines / params files in SpawnAction.Gravatar tomlu2017-09-15
| | | | | | This is necessary for the upcoming Skylark implementation of param files. PiperOrigin-RevId: 168744486
* Do not flatten resource artifacts in Android rules.Gravatar tomlu2017-09-15
| | | | | | This involves rather tediously rolling up each artifact type in its own individual nested set. PiperOrigin-RevId: 168729120
* 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-03 17:26:22 +0000