aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android/DexArchiveAspect.java
Commit message (Collapse)AuthorAge
* Return Java providers only onceGravatar elenairina2018-08-02
| | | | | | | through JavaInfo, instead of returning them also through ConfiguredTarget. Since these providers can not be found in ConfiguredTarget anymore they have to be retrieved from JavaInfo instead. RELNOTES: None. PiperOrigin-RevId: 207068520
* Automated rollback of commit 38899f708923d6a7e1edd011af2ba70f505bb4c9.Gravatar twerth2018-08-01
| | | | | | | | | | | | | | | *** Reason for rollback *** Necessary for [] *** Original change description *** Return Java providers only once through JavaInfo, instead of returning them also through ConfiguredTarget. Since these providers can not be found in ConfiguredTarget anymore they have to be retrieved from JavaInfo instead. RELNOTES: None. PiperOrigin-RevId: 206915058
* Return Java providers only onceGravatar elenairina2018-07-30
| | | | | | | through JavaInfo, instead of returning them also through ConfiguredTarget. Since these providers can not be found in ConfiguredTarget anymore they have to be retrieved from JavaInfo instead. RELNOTES: None. PiperOrigin-RevId: 206585413
* Automated rollback of commit 64ea3cd90e1ead5ece533ee5a3cb4ee3520527fb.Gravatar Googler2018-07-20
| | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Update the Flutter rules AndroidSdkInfo provider to FlutterAndroidSdkInfo. AndroidSdkInfo should be unique in the repo now. *** Original change description *** Automated rollback of commit 4d10250291a813302de64151be3b22d57e94749d. *** Reason for rollback *** AndroidSdkInfo is already being used by the Flutter rules. *** Original change description *** Expose AndroidSdkProvider to Skylark (as AndroidSdkInfo). RELNOTES: None. PiperOrigin-RevId: 205431461
* Automated rollback of commit 4d10250291a813302de64151be3b22d57e94749d.Gravatar Googler2018-07-18
| | | | | | | | | | | | | *** Reason for rollback *** AndroidSdkInfo is already being used by the Flutter rules. *** Original change description *** Expose AndroidSdkProvider to Skylark (as AndroidSdkInfo). RELNOTES: None. PiperOrigin-RevId: 205142459
* Expose AndroidSdkProvider to Skylark (as AndroidSdkInfo).Gravatar Googler2018-07-17
| | | | | RELNOTES: None. PiperOrigin-RevId: 204983634
* Replace instances of Blaze with Bazel.Gravatar Dan Fabulich2018-07-05
| | | | | | | PiperOrigin-RevId: 203300374 Change-Id: Iaa47f870ab2e0cad40a202aad2c7f9430f73c856 PiperOrigin-RevId: 203407392
* Expose aspect actions from Skylark.Gravatar tomlu2018-06-22
| | | | | | | | | | | Like with providers, consumers get a merged view of all actions from the merged configured target (all other aspects + the base target). I had to rejig the aspect value / configured aspect to be symmetric with rule configured targets. I do not expect significant memory bloat from this. All lists / maps already existed, only extra fields have been added. RELNOTES: Expose aspect actions provider to Skylark. PiperOrigin-RevId: 201697923
* Make some Android things more serializable.Gravatar janakr2018-06-19
| | | | PiperOrigin-RevId: 201228699
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-02
| | | | PiperOrigin-RevId: 195100125
* Preemptively propagate DexArchiveAspect to skylark _toolchain attributesGravatar kmb2018-04-27
| | | | | | This allows incremental dexing to work with any Skylark rules that have implicit runtime dependencies. Rules should define a _toolchain attribute pointing to a Skylark toolchain. The toolchain should list all implicit runtime dependencies in a "runtime" attribute. PiperOrigin-RevId: 194611124
* Use JavaRuleOutputJarsProvider to collect non-transitive runtime jarsGravatar cushon2018-04-24
| | | | PiperOrigin-RevId: 194170571
* Make some runtime jar collection non-transitiveGravatar cushon2018-04-24
| | | | PiperOrigin-RevId: 194138150
* Add getters to JavaCompilationArgsProviderGravatar cushon2018-04-24
| | | | | | | | | | for direct, transitive, and full compile-time jars; runtime jars; and instrumentation metadata. These are trivial wrappers around the corresponding getters on the recursive and non-recursive JavaCompilationArgs objects. This is a no-op refactoring in preparation for flatting JavaCompilationArgs into JavaCompilationArgsProvider. PiperOrigin-RevId: 194047064
* Clean up IterablesChain.Gravatar tomlu2018-04-18
| | | | | | | | | | | * Change builder return type to Iterable<T> instead of IterableChain<T>. It is over-specified and unnecessary to state the return type so precisely. * Optimize builder for cases where we add 0 or 1 iterables to the chain. In this case, we can simply return the underlying iterables without adding wrappers. * Extract DedupingIterable, it doesn't have anything to do with IterablesChain and is only used in one place RELNOTES: None PiperOrigin-RevId: 193363048
* Remove JavaRuntimeJarProvider.Gravatar elenairina2018-04-13
| | | | PiperOrigin-RevId: 192736049
* Add BuildConfiguration to ConfiguredTargetAndTarget and rename it to ↵Gravatar janakr2018-03-10
| | | | | | ConfiguredTargetAndData. We want to get BuildConfiguration out of ConfiguredTarget because it uses >800K when serialized. PiperOrigin-RevId: 188600002
* Use a separate implicit dependency for dexbuilder in proguarded android buildsGravatar kmb2018-02-21
| | | | | | RELNOTES: None. PiperOrigin-RevId: 186511953
* Adds ObjectCodecRegistry to {Des|S}erializationContext.Gravatar shahan2018-02-20
| | | | | | | | | | | | * AutoCodec now delegates to the registry. * Adds getSuperclass logic for resolving a codec. * Small cleanups for classes that break the registry. TODO after this change: * Explicit CODEC definitions are no longer needed and existing ones should be cleaned up. * POLYMORPHIC is no longer be needed and should be cleaned up. PiperOrigin-RevId: 186351845
* 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
* Add Codec for NativeAspectClass. As a result, remove @AutoCodec from ↵Gravatar janakr2018-02-13
| | | | | | | | concrete subclasses. Improve debugging message on serialization failures. Lot of test-side changes to make sure aspects are properly registered with the RuleClassProvider. PiperOrigin-RevId: 185607202
* Move common proto aspect logic to a new class.Gravatar elenairina2018-02-12
| | | | PiperOrigin-RevId: 185369902
* Hooks to support core library desugaring in Android buildsGravatar kmb2018-02-07
| | | | | | RELNOTES: None. PiperOrigin-RevId: 184909685
* Non-test AspectClass codecs.Gravatar shahan2018-02-07
| | | | PiperOrigin-RevId: 184862552
* RELNOTES: stop using --no-locals in android coverage buildsGravatar kmb2018-02-02
| | | | PiperOrigin-RevId: 184369667
* Change ConfiguredAspectFactory.create signature to take in aGravatar mjhalupka2018-01-31
| | | | | | | ConfiguredTargetAndTarget instead of a ConfiguredTarget. This is to assist in deprecating ConfiguredTarget.getTarget(). PiperOrigin-RevId: 184043491
* use built-in params file support in DexArchiveAspectGravatar kmb2018-01-09
| | | | | | RELNOTES: None. PiperOrigin-RevId: 181397098
* Remove defunct Android incremental dexing flagsGravatar kmb2018-01-04
| | | | | | RELNOTES: Remove defunct flags --experimental_incremental_dexing_for_lite_proto and --experimental_incremental_dexing_error_on_missed_jars that have long been enabled by default PiperOrigin-RevId: 180821902
* Change cfg(HOST) to cfg(HostTransition.INSTANCE).Gravatar gregce2017-12-21
| | | | | | Preparatory step for removing ConfigurationTransition.HOST. PiperOrigin-RevId: 179838374
* Automatic formatting cleanup of Android *.java files.Gravatar jingwen2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179425421
* Support incremental dexing tools in proguarded Android buildsGravatar kmb2017-11-17
| | | | | | RELNOTES: None. PiperOrigin-RevId: 176109497
* Remove --incremental_dexing_binary_types.Gravatar ajmichael2017-10-31
| | | | | | | It has been set to all for a bit now. It is not in any teams blazerc/tap configs. RELNOTES: --incremental_dexing_binary_types has been removed. All builds are supported by incremental dexing (modulo proguard and some blacklisted dx flags). PiperOrigin-RevId: 173931117
* Return JavaInfo providers only once in Java rules.Gravatar elenairina2017-10-11
| | | | | | | Previously the java rules returned some providers twice: once as regular providers and once wrapped in JavaInfo (e.g. JavaCompilationArgsProvider). This is unnecessary, inefficient and error prone. JavaInfo should be the only way of returning these providers. RELNOTES: None. PiperOrigin-RevId: 171663550
* Add flag to Blaze to double-check correct desugaring in Android deploy.jarsGravatar kmb2017-09-29
| | | | | | (without affecting other uses of singlejar) PiperOrigin-RevId: 170411730
* LateBoundDefault: enforce access to a single fragment (or none).Gravatar mstaib2017-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, there is no way to enforce that LateBoundDefaults only access the fragments that they declare. This means that LateBoundDefaults can fail to declare fragments at all, or declare the wrong ones, and still have no troubles. But when trimming, these fragments must be declared, because otherwise they will not necessarily be available. This change refactors LateBoundDefault to declare a single fragment type, not a set. All existing LateBoundDefaults use sets with a single element or no elements at all for their set of fragment classes, so this does not limit anything being done currently. To account for LateBoundDefaults which do not use configuration at all, typically those which only want to access the configured attribute map, it is possible for Void to be the fragment class which is requested. To account for LateBoundDefaults which need to access methods of the BuildConfiguration instance itself, it is possible for BuildConfiguration to be the fragment class which is requested; however, this is unsafe, so it is only a temporary state until a way to do this without also giving access to all of the fragments can be added. Drive-by refactoring: LateBoundDefaults' values are now typed. All actual production LateBoundDefaults were Label or List<Label> typed, through the LateBoundLabel and LateBoundLabelList subclasses. These subclasses have been removed, and LateBoundDefault has two type parameters, one for the type of its input, and one for the type of its output. RELNOTES: None. PiperOrigin-RevId: 169242278
* 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
* Inline CustomCommandLine methods that can be expressed using VectorArg.Gravatar tomlu2017-09-12
| | | | | | This whole CL was done using IDE refactoring tools and should be safe. PiperOrigin-RevId: 168275575
* make local worker mode configurable for dexbuilderGravatar kmb2017-09-06
| | | | | | RELNOTES: none PiperOrigin-RevId: 167608048
* Android,Windows: use default shell env in actionsGravatar Laszlo Csomor2017-09-01
| | | | | | | | | | | | | | | | | | | | Bazel now creates all SpawnActions in AndroidBinary, AndroidCommon, and DexArchiveAspect such that they use the default shell environment. The benefit of this is that these actions will have a well-controlled, minimal environment, and most importantly they'll have valid TMP and TEMP environment variables, which is necessary for temp file creaion on Windows. I created this commit for the same reason as https://github.com/bazelbuild/bazel/commit/0abf5fa2d64c76def5a8fa0f960b73ce0566af4d See https://github.com/bazelbuild/bazel/issues/3659 Change-Id: Ice42ea6424af8984d3c382ab01727e04cbd0c1b4 PiperOrigin-RevId: 167285724
* Use CustomCommandLine directly instead of via SpawnAction.Builder.Gravatar tomlu2017-08-23
| | | | | | | | | | | | | 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: 166104375
* Improve CustomCommandLine interface.Gravatar tomlu2017-08-22
| | | | | | | | | | | | | | | | In converting SpawnAction.Builder (multi-thousand line CL) users directly to CustomCommandLine I didn't like the resulting loss of readability, and the methods didn't feel very discoverable. Unless it's very convenient and readable to use CustomCommandLine, people will resort to non-memory efficient patterns by default. I'm holding that CL for this, which should offer a nicer interface. This CL removes VectorArg from the API contact surface area, instead creating 64 overloads for every valid combination of parameters. Pretty sad, but the methods dispatch straight to internal helper methods so it's mostly boilerplate to the tune of +400 LOC. Other changes: * Change ImmutableCollection -> Collection and copy the args directly into the internal args vector. Saves on collection object overhead and saves users from having to create immutable copies. * Change some names, notably add -> addAll for collection methods * Create additional missing overloads * Fix JavaDoc RELNOTES: None PiperOrigin-RevId: 165943879
* 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
* 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
* Improve CustomCommandLine.Gravatar tomlu2017-08-10
| | | | | | | | | | | | | Instead of having custom ArgvFragments for every combination of desired things, we make a combined "interpreter" of argvs. This saves memory and simplifies things as we do not have to allocate a strategy instance per call to args (instead pushing a single shared instance, followed by the args). The generic interpreter does have a lot of branching compared to the bespoke implementations, but because the branch is always the same for long stretches the branch predictor should easily be able to handle it with minimal overhead (~1 cycle per branch IIRC). This CL also elevates that we either want a NestedSet or an ImmutableCollection to the surface of the API, so consumers understand the cost when they call it with a non-immutable collection. Most of the changes in clients is due to this. To cut down on CL churn, @Deprecated forwarding methods are added to CustomCommandLine. These will be removed in a separate CL using IDE inlining. RELNOTES: None PiperOrigin-RevId: 164725370
* 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
* Move WrappingProviderHelper into static class in WrappingProvider.Gravatar Googler2017-06-20
| | | | | | Cuts down on file count and makes it easier to find these methods. PiperOrigin-RevId: 159560422
* Create a general WrappingProvider concept and use for java_proto_library and ↵Gravatar Googler2017-06-20
| | | | | | | | | | | | friends. The wrapping provider contains its own provider map containing any providers that may conflict. This can be used generally for any aspect that wants to override its base providers (during migration), and due to the generality we should be able to cut down on code size and complexity. Once we have this, we can more easily and uniformly bind aspects to Skylark for aspect-on-aspect functionality. The Skylark providers can be instantiated with a wrapping provider if one is present, or fall through to the base target if they aren't. We will also likely save a bit of memory from cutting down on wrapping classes. PiperOrigin-RevId: 159461325
* Don't create the same String/ImmutableMap over and over again.Gravatar twerth2017-06-09
| | | | | RELNOTES: None PiperOrigin-RevId: 158498863
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-01 05:05:28 +0000