aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android/AndroidResourceParsingActionBuilder.java
Commit message (Collapse)AuthorAge
* 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
* Reduce and centralize databinding context instances.Gravatar corysmith2018-08-03
| | | | | | | Due to some of the vagaries of skylark and multiple entry points, the databinding context is currently updated by the parse action. RELNOTES: None PiperOrigin-RevId: 207333111
* Use independently passed assets in aapt2 packaging as wellGravatar asteinb2018-05-29
| | | | | | | | | | | | | | Much earlier, I made a change that allowed passing assets without resources to aapt packaging. Do the same for aapt2 packaging too. The busybox seems to be expecting compiled symbols, so compile assets and pass the compiled version in. (Compiling assets doesn't save any time, but doesn't cost much either, and means that we'll eventually be able to phase out the parsed form entirely. Adapting the Busybox to take parsed assets would probably work too, but getting the code to handle it would be really messy.) RELNOTES: none PiperOrigin-RevId: 198417111
* 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
* Independently parse assetsGravatar asteinb2018-04-16
| | | | | | | This is the first step in processing assets completely seperately from resources. RELNOTES: none PiperOrigin-RevId: 193076991
* Properly expose resource artifacts in MergableAndroidData interfaceGravatar asteinb2018-04-16
| | | | | | | | | | | In hindsight, I should have done this a few changes ago, but the relevant change is already submitted. We need the artifacts for use in some cases where we want to use AndroidResources and ResourceContainer interchangably during migration. RELNOTES: none PiperOrigin-RevId: 193038067
* Add skipped manifest processing methodsGravatar asteinb2018-04-11
| | | | | | | | | | | Add some required manifest support I didn't previously implement: - Support for exports_manifest field - Get properly processed manifest from AndroidSemantics - Correctly represent the current relationship between manifest and resource processing - resource processing uses the stamped manifest. RELNOTES: none PiperOrigin-RevId: 192508962
* Add methods to parse resources without assetsGravatar asteinb2018-04-03
| | | | | | | | | | | | | | - Add ParsedAndroidResources to wrap AndroidResources and resource parsing output. - Implement parse() method in AndroidResources, and support for it elsewhere - Move some supporting methods to the right place (setting up an aapt2 sdk for tests goes to the base test rule, and creating a dummy DataBinding zip goes to the DataBinding class). - Tests for new parse() method, including support for getting a test RuleContext instance RELNOTES: none PiperOrigin-RevId: 191436027
* Pass resources and assets seperately into parse and compile actionsGravatar asteinb2018-03-29
| | | | | | | | | | | This will eventually allow us to parse or compile assets and resources separately. Also, remove a no-op null check that was making the code confusing, and some unneeded resource filtering that was doing the same. RELNOTES: none PiperOrigin-RevId: 190951667
* Rename LocalResourceContainer to AndroidResources and remove asset code from itGravatar asteinb2018-03-29
| | | | | | | | | | | | | As part of decoupling Android resources and assets, rename LocalResourceContainer to AndroidResources and remove asset code from it. Some general asset and manfiest code still remains and will be dealt with in future changes. Remove LocalResourceContainer from the ParsingActionBuilder, since it's always used to build the ResourceContainer that is subsequently passed in. RELNOTES: none PiperOrigin-RevId: 190945260
* 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
* Produce data binding file from compile action when "enable_data_binding" ↵Gravatar Googler2018-01-10
| | | | | | | attribute is on. RELNOTES: none PiperOrigin-RevId: 181503682
* Automatic formatting cleanup of Android *.java files.Gravatar jingwen2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179425421
* 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
* Add aapt2 to the resource compile action.Gravatar corysmith2017-08-17
| | | | | RELNOTES: None PiperOrigin-RevId: 165469671
* 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
* Enable aapt2 support in library actions.Gravatar corysmith2017-06-29
| | | | | RELNOTES: None PiperOrigin-RevId: 160445869
* 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
* Add getImplicitOutputArtifact to BuildViewTestCase. This vastly simplifiesGravatar Googler2017-01-23
| | | | | | | | finding actions based on intermediate artifacts. -- PiperOrigin-RevId: 145303065 MOS_MIGRATED_REVID=145303065
* Add a resource parsing action.Gravatar Googler2016-07-28
Part of 3 proposed new actions: - parsing action - merging action - validating action Dependencies (directData and transitiveData) expect the symbol files. If the merge action produces the symbol files, then each merge action depends on each other. Instead, produce it in an action with just source resources as prereqs to allow more parallelism. Technically, we don't need a manifest as part of the parameters. I debated about whether to introduce a basic version of UnvalidatedAndroidData or not. -- MOS_MIGRATED_REVID=128599714
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-01 05:36:33 +0000