aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android/ManifestMergerActionBuilder.java
Commit message (Collapse)AuthorAge
* Move non-resource busybox actions to BusyBoxActionBuilder and AndroidDataContextGravatar asteinb2018-05-22
| | | | | | | | | | | | | 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). Remaining action builders will be moved in the next change. Add old manifest merger tool to AndroidDataContext. RELNOTES: none PiperOrigin-RevId: 197607155
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-02
| | | | PiperOrigin-RevId: 195100125
* Normalize parameter name commentsGravatar cushon2018-04-27
| | | | PiperOrigin-RevId: 194512971
* Add AndroidManifest and related classes for new manifest merging implementationGravatar asteinb2018-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | AndroidManifest represents a new class to handle decoupled Android manifest processing (as opposed to the existing ApplicationManifest, which handles manifests, resources, and assets all together). This new manifest processing pipeline will be used by the Skylark Android Data API. AndroidManifest wraps the manifest and related information, so we don't just pass around untyped Artifacts all the time. Additionally, the StampedAndroidManifest subclass explicitly states that a manifest has been stamped with the correct package (previous confusion between passing around the stamped and unstamped manifests has led to bugs in Blaze). Unlike the old manifest processing pipeline, AndroidManifest: - Does not support the old legacy manifest merger - Is decoupled from resource and asset processing - Does incremental merges - Always has the package defined at analysis time - Can be run without an input manifest (for rules which don't specify their own manifest but either inherit manifests that should be merged or to provide a dummy manifest for tooling) RELNOTES: none PiperOrigin-RevId: 190119992
* 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
* Automated rollback of commit 4260c30a03a9b83d48a5e8690aca19cd80be4c38.Gravatar ulfjack2018-02-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Try again with fixes. *** Original change description *** Automated rollback of commit 10b0d8aa6b73a024cc007c5e075cb329add878ef. *** Reason for rollback *** Breaks Google-internal targets, sadly. *** Original change description *** Ban middlemen from runfiles artifacts. Previous changes have removed all middlemen from runfiles artifacts. This CL locks it down and removes various now-redundant *WithoutMiddlemen() methods from Runfiles. I put a check for middlemen in ConflictChecker.put, which should be a chokepoint for runfiles arti... *** PiperOrigin-RevId: 184661375
* Automatic formatting cleanup of Android *.java files.Gravatar jingwen2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179425421
* Automated rollback of commit 10b0d8aa6b73a024cc007c5e075cb329add878ef.Gravatar lberki2017-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks Google-internal targets, sadly. *** Original change description *** Ban middlemen from runfiles artifacts. Previous changes have removed all middlemen from runfiles artifacts. This CL locks it down and removes various now-redundant *WithoutMiddlemen() methods from Runfiles. I put a check for middlemen in ConflictChecker.put, which should be a chokepoint for runfiles artifacts. It's unfortunate we can't detect middlemen earlier than execution, but I can't see a way to efficiently check every runfiles artifact earlier. Cha... *** RELNOTES: None. PiperOrigin-RevId: 175650018
* Ban middlemen from runfiles artifacts.Gravatar Benjamin Peterson2017-11-10
| | | | | | | | | | | | | | Previous changes have removed all middlemen from runfiles artifacts. This CL locks it down and removes various now-redundant *WithoutMiddlemen() methods from Runfiles. I put a check for middlemen in ConflictChecker.put, which should be a chokepoint for runfiles artifacts. It's unfortunate we can't detect middlemen earlier than execution, but I can't see a way to efficiently check every runfiles artifact earlier. Change-Id: I57fcb51b02e40adf3ebc4591c26bf5492c89352f PiperOrigin-RevId: 175206157
* 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
* Rollforward of ↵Gravatar apell2017-08-29
| | | | | | | | | https://github.com/bazelbuild/bazel/commit/0071b396776be4d146fd271499716dd5dea6f7e9: Enable parameter files for manifest merger actions. NEW: Using shell quoted param files and unescape arguments in ParamsFilePreProcessor to avoid miss-processing --manifestValues arguments containing whitespace. RELNOTES: None. PiperOrigin-RevId: 166858411
* Automated rollback of commit d31a944cfae27564caa7f974e0daec99314d4c44.Gravatar lberki2017-08-24
| | | | | | | | | | | | | *** Reason for rollback *** Breaks //java/com/google/commerce/tapandpay/android/app/alienfood:<things> *** Original change description *** Enable parameter files for manifest merger actions. RELNOTES: None. PiperOrigin-RevId: 166324224
* Enable parameter files for manifest merger actions.Gravatar apell2017-08-24
| | | | | RELNOTES: None. PiperOrigin-RevId: 166215145
* 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
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* 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 target label to progress messages for some Android build actions.Gravatar Andrew Pellegrini2016-09-26
| | | | | -- MOS_MIGRATED_REVID=134118816
* Add manifest merger output log.Gravatar Andrew Pellegrini2016-09-26
| | | | | | | RELNOTES: When using android_binary.manifest_merger="android" the merger produces a summary log next to the merged manifest artifact. -- MOS_MIGRATED_REVID=134082985
* Add target names for mergee manifests to generate more helpful error ↵Gravatar Andrew Pellegrini2016-07-20
| | | | | | | messages from manifest merging when using manifest_merger="android" on android_binary rules. -- MOS_MIGRATED_REVID=127962630
* Adds the Android manifest merger as an option for android_binary rules. The ↵Gravatar Andrew Pellegrini2016-06-23
merger that is used (legacy or android) is controlled by the manifest_merger attribute on android_binary and the default is controlled by the --android_manifest_merger flag. RELNOTES: The Android manifest merger is now available as an option for android_binary rules. The merger will honor tools annotations in AndroidManifest.xml and will perform placeholder substitutions using the values specified in android_binary.manifest_values. The merger may be selected by setting the manifest_merger attribute on android_binary. -- MOS_MIGRATED_REVID=125603954
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-03 23:27:48 +0000