aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules
Commit message (Collapse)AuthorAge
* Adding a check to verify the usage of the migration tag for the SkylarkGravatar Googler2018-04-27
| | | | | | | migration, when a flag is enabled. RELNOTES: PiperOrigin-RevId: 194630925
* 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
* Change action construction to use built-in param file support.Gravatar tomlu2018-04-27
| | | | | | | | | | | We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall. For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo". However, the name of the param file is now derived from the primary output of the action (instead of manually controlled). RELNOTES: None PiperOrigin-RevId: 194607698
* Ensure that all aspects which (even very indirectly) callGravatar jcater2018-04-27
| | | | | | | CppHelper.getToolchainFromPlatformConstraints declare that they require a cc toolchain. PiperOrigin-RevId: 194580065
* Ensure that all rules which (even very indirectly) callGravatar jcater2018-04-27
| | | | | | | CppHelper.getToolchainFromPlatformConstraints declare that they require a cc toolchain. PiperOrigin-RevId: 194561293
* Do not add flags from linking_mode_flags section when the toolchain definesGravatar hlopko2018-04-27
| | | | | | | | | | | | | | | | corresponding features. Therefore when both linking_mode_flags { mode: DYNAMIC } and feature { name: "dynamic_linking_mode" } are provided, bazel will only take flags from the feature. The same applies to mode: STATIC and static_linkin_mode feature respectively. mode: MOSTLY_STATIC_LIBRARIES is covered under dynamic_linking_mode for action "c++-link-dynamic-library". mode: FULLY_STATIC is handled separately. This is needed to provide a way of incremental migration towards legacy-flags-free crosstool. RELNOTES: None. PiperOrigin-RevId: 194556688
* Normalize parameter name commentsGravatar cushon2018-04-27
| | | | PiperOrigin-RevId: 194512971
* Automated rollback of commit 8ca66458a42266f11aba77732b05ab06b96e95fb.Gravatar hlopko2018-04-26
| | | | PiperOrigin-RevId: 194506134
* Ensure that all rules which (even very indirectly) callGravatar jcater2018-04-26
| | | | | | | CppHelper.getToolchainFromPlatformConstraints declare that they require a cc toolchain. PiperOrigin-RevId: 194504473
* Make mobile-install shard for extra .dex file produced with ↵Gravatar kmb2018-04-26
| | | | | | --experimental_desugar_java8_libs PiperOrigin-RevId: 194462758
* RuleTransitionFactory returns NoTransition instead of null.Gravatar mstaib2018-04-26
| | | | | RELNOTES: None. PiperOrigin-RevId: 194433721
* Remove unused method.Gravatar jcater2018-04-26
| | | | PiperOrigin-RevId: 194430205
* CppDebugPackageProvider is useful for more than just C++, so rename it.Gravatar Googler2018-04-26
| | | | | RELNOTES: None. PiperOrigin-RevId: 194429584
* Consolidating start/end lib archive expansionGravatar Googler2018-04-26
| | | | | | | | Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command line. RELNOTES: Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent. PiperOrigin-RevId: 194400112
* Automated rollback of commit c5c6ef83936cf90fd11038a84637e691beb47288.Gravatar tomlu2018-04-26
| | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** b/78577719 *** Original change description *** Change action construction to use built-in param file support. We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall. For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo". However, the name of the param file is now derived from the primary... *** RELNOTES: None PiperOrigin-RevId: 194389749
* Expose cc_common.get_environment_variables and cc_common.get_command_line to ↵Gravatar hlopko2018-04-26
| | | | | | | | | | | | | skylark This cl enabled skylark rules to compute the command line using feature configuration, the same mechanism that native C++ rules use. Working towards #4571. RELNOTES: CppRules: C++ command lines and env variables for C++ actions can be retrieved from feature configuration. PiperOrigin-RevId: 194384637
* Add an extra argument to CcCompilationHelper#fromCommon() that contains ↵Gravatar lberki2018-04-26
| | | | | | | additional compiler options. RELNOTES: None. PiperOrigin-RevId: 194363080
* Automated rollback of commit 404483d99bca4edc0600e72cacfcc36404fd4653.Gravatar hlopko2018-04-25
| | | | | | RELNOTES: None. PiperOrigin-RevId: 194353580
* Support deferred param files.Gravatar tomlu2018-04-25
| | | | | | | | | | | | | Design doc: https://docs.google.com/document/d/1JXqwwVHYosZOgmjN8xrfTalyhiUYJ99Qe2D0qBcqZ1c The behaviour is gated on --defer_param_files (default off) and is controlled by --min_param_file_size. This CL adds support for VirtualActionInputs to LocalSpawnRunner, and all remote runners already supports them. The sandboxed runners are not yet supported, but that can be added in a future CL. This CL does not add support for spawn runner using different param file limits. This will require refactoring of the spawn strategies and runners to be viable. RELNOTES: None PiperOrigin-RevId: 194265291
* Make java_common.compile's javacopt handling consistent with native Java rulesGravatar cushon2018-04-25
| | | | | | | | | | | Compilations performed by java_common.compile now use the javacopts in the java_toolchain by default, instead of requiring them to be explicitly retrived using java_common.default_javac_opts, for consistency with the native rules. java_common.compile(javac_opts=...) can still be used to pass additional javacopts. RELNOTES: Make java_common.compile now uses java_toolchain javacopts by default; explicitly retrieving them using java_common.default_javac_opts is unnecessary. PiperOrigin-RevId: 194254098
* Add an extra argument to CcCompilationHelper#fromCommon() that contains ↵Gravatar lberki2018-04-25
| | | | | | | additional compiler options. RELNOTES: None. PiperOrigin-RevId: 194232650
* Make output name case-insensitive while calculating output names for object ↵Gravatar pcloudy2018-04-25
| | | | | | | | | files This change is due to Windows and macOS, where file paths are case-insensitive RELNOTES: PiperOrigin-RevId: 194223755
* Replace usage of proto class CToolchain.WithFeatureSet with equivalent ↵Gravatar Googler2018-04-25
| | | | | | | WithFeatureSet class RELNOTES: None. PiperOrigin-RevId: 194218956
* Refactor generated objc sources compilation in ProtobufSupport.javaGravatar pcloudy2018-04-25
| | | | | | | Moving CompilationSupport out of for loop. All generated object-c files will be compiled in one CompilationHelper, which avoids object file path conflicts. RELNOTES: None PiperOrigin-RevId: 194215804
* Change action construction to use built-in param file support.Gravatar tomlu2018-04-25
| | | | | | | | | | | We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall. For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo". However, the name of the param file is now derived from the primary output of the action (instead of manually controlled). RELNOTES: None PiperOrigin-RevId: 194208049
* Remove no-op check from AndroidCommon, add missing rule validation to aar_importGravatar kmb2018-04-24
| | | | PiperOrigin-RevId: 194191933
* Pass environment to Skylark provider constructors.Gravatar tomlu2018-04-24
| | | | | | | This is needed for constructors that want to be able to use SkylarkSemantics. RELNOTES: None PiperOrigin-RevId: 194180124
* Make the static_link_cpp_runtimes feature settableGravatar Googler2018-04-24
| | | | | | | | | | | as a normal feature. Prior to this cl, it was always set by examining supports_embedded_runtimes. DELTA_BY_EXTENSION=java=100,py=15 RELNOTES: None PiperOrigin-RevId: 194172053
* Change action construction to use built-in param file support.Gravatar tomlu2018-04-24
| | | | | | | | | | | We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall. For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo". However, the name of the param file is now derived from the primary output of the action (instead of manually controlled). RELNOTES: None PiperOrigin-RevId: 194171911
* Use JavaRuleOutputJarsProvider to collect non-transitive runtime jarsGravatar cushon2018-04-24
| | | | PiperOrigin-RevId: 194170571
* Automated rollback of commit 77777d1a769e938839b82c65ff320e09b1e7a715.Gravatar Googler2018-04-24
| | | | | | | | | | | | | | | | | | This CL includes the rollback + better fix for issue #4922. https://github.com/bazelbuild/bazel/issues/4922 *** Reason for rollback *** Breaks mobile-install v2 adb port forwarding, b/78432638 *** Original change description *** Fix crash from mobile-install with --device but no --adb_args. Fixes #4922. RELNOTES: None PiperOrigin-RevId: 194155557
* Fix runtime jar collection for legacy mobile-installGravatar cushon2018-04-24
| | | | PiperOrigin-RevId: 194151342
* Make some runtime jar collection non-transitiveGravatar cushon2018-04-24
| | | | PiperOrigin-RevId: 194138150
* Remove JavaConstraintsProvider, allow specifying constraints when ↵Gravatar kmb2018-04-24
| | | | | | constructing JavaInfo providers instead PiperOrigin-RevId: 194123199
* Add new-style JavaInfo provider constructor.Gravatar tomlu2018-04-24
| | | | | | | | | | | | Design: https://docs.google.com/document/d/1ubah6phuvWnugShtVgSQnaopQ1BtKtNxQASVwGZA7k0/ * Moves action construction out into java_common.run_ijar, java_common.pack_sources * Deprecates corresponding arguments in JavaInfo An incompatible flag will be added in another CL since it is not possible to add incompatible flags at the same time as new functionality is added. RELNOTES: Adds new-style JavaInfo provider constructor. PiperOrigin-RevId: 194111925
* Ensure make variables from the CcToolchainProvider end up in theGravatar jcater2018-04-24
| | | | | | TemplateVariableInfo. PiperOrigin-RevId: 194088329
* Make the constructor of TemplateVariableInfo available in Skylark.Gravatar lberki2018-04-24
| | | | | | RELNOTES[NEW]: TemplateVariableInfo can now be constructed from Skylark. PiperOrigin-RevId: 194072452
* Properly report completion of shared actions with input discoveryGravatar hlopko2018-04-24
| | | | | | | | | | | | | | Currently we report "Analyzing" when include scanning runs. But since we can have shared C++ compile actions, only one of the group will be executed and only one will be reported completed. Remaining shared actions currently stay with "analyzing" forever. This cl makes sure that these actions are properly handled when finished. This is an encore of https://github.com/bazelbuild/bazel/commit/24f19ec2679dd93b1ac5b06e46f3b35807d6e217. In this incarnation I make sure that all actions that discover inputs are consistent in reporting their Analyzing status. Originally only CppCompileAction was doing that. Apparently we have more actions that discover inputs (e.g. LtoBackendAction) but these were not reporting Analyzing and therefore crashing on preconditions. This cl makes sure that all actions discovering inputs report their analyzing status. RELNOTES: None PiperOrigin-RevId: 194066513
* Allow feature configuration to be created from skylarkGravatar hlopko2018-04-24
| | | | | | | Working towards #4571. RELNOTES: CppRules: Feature configuration can be created from Skylark PiperOrigin-RevId: 194048906
* 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
* Cleanup LibraryToLinkCollector to properly distinguish C++ runtimes from ↵Gravatar hlopko2018-04-24
| | | | | | | | | | | | | | | | dynamic libraries Term runtime input had 2 meanings in CppLinkAction: 1) input needed at runtime - dynamic library 2) input corresponding to the C++ runtime (libstdc++ or libc++) This confused me and therefore the code :) This cl cleans this up to some extent by: * renaming runtimeInput to runtimesInput, to at least give the reader a chance to catch the difference :) * treating runtimesInputs as normal linker inputs, also downstream in CppLinkAction and LinkCommandLine * Simplifying LibrariesToLinkCollector by removing explicit runtimesHandling. RELNOTES: None PiperOrigin-RevId: 194046439
* Accept included headers which are provided by tree artifacts.Gravatar carmi2018-04-23
| | | | | | | This allows a C++ file to include headers from a tree artifact, and pass header inclusion checks. RELNOTES: None. PiperOrigin-RevId: 193967617
* Add the additional options to support manual trimming of feature flags.Gravatar mstaib2018-04-23
| | | | | | | | | | | | | | | | | | | There are effectively three different states a flag's value could be in: 1. Value is known to be non-default 2. Value is known to be default 3. Value is unknown (has been trimmed) In addition to flagValues (which covers the first state), there are now two additional sets covering the other two states. Neither of these sets are used when manual trimming is disabled or when the entire set of flags is known, in which case state 1 is represented by labels in the map, state 2 is represented by labels not in the map, and state 3 doesn't exist. This also adds the flag which controls whether manual trimming is active, but it currently has no effect. RELNOTES: None. PiperOrigin-RevId: 193964624
* Add a new "STRICT_ERROR" for the flag "--experimental_import_deps_checking" ↵Gravatar cnsun2018-04-23
| | | | | | | | | to check the direct dependencies for aar_import targets. Currently the default value of this flag is not changed. And it will be enabled in a separate cl. RELNOTES: None PiperOrigin-RevId: 193959866
* C++: Expose functionality needed for cc_embed_data Skylark implementationGravatar plf2018-04-23
| | | | | RELNOTES:none PiperOrigin-RevId: 193919970
* SpawnAction.setShellCommand: expect shell pathGravatar laszlocsomor2018-04-23
| | | | | | | | | | | | | | | | | | | | | | | SpawnAction.setShellCommand(String) now expects the shell interpreter's path as an argument. This change enables two things: - rules can report an error if the shell is missing - SpawnAction no longer has to know about a default shell The new ShToolchain class will later also be responsible for retrieving the active shell toolchain (added in https://github.com/bazelbuild/bazel/commit/81ed3add408adb20bddbc3ba1818c65806738dc5). This change brings Bazel closer to not depend on the shell unless it has to (e.g. to run shell scripts). See https://github.com/bazelbuild/bazel/issues/4319 RELNOTES: none PiperOrigin-RevId: 193885943
* aar_import doesn't export AndroidSkylarkApiProviderGravatar asteinb2018-04-20
| | | | | | | | aar_import probably should give IDEs the same information as other rules, but it doesn't at the moment. Stop exporting the corresponding provider. RELNOTES: none PiperOrigin-RevId: 193701950
* Fix asset processing bugGravatar asteinb2018-04-20
| | | | | | | | | | We need to pass primary asset and resource artifacts to processing, not just resources. This was introduced as part of my recent migration. In my defense, this migration was needed exactly to avoid situations like this (ResourceContainer.getArtifacts does not just return resource artifacts like you might expect it to). RELNOTES: none PiperOrigin-RevId: 193693868
* Expose new methods in CcToolchainProvider to eventually replace skylark ↵Gravatar juliexxia2018-04-20
| | | | | | callables that depend on CToolchain in CppConfiguration. PiperOrigin-RevId: 193690345
* Optionally suppress ThinLTO indexing for all linkstatic targetsGravatar Googler2018-04-20
| | | | | | | | | | | | | | | This extends the scalability fix in https://github.com/bazelbuild/bazel/commit/8c5e290dfab3cab378a9ca107ecdd6267403cd4b to optionally apply to all statically linked targets. Some test invocations end up building non-testonly cc_binary that are in the transitive data deps of a test, and can lead to huge numbers of LTO backend jobs for those test invocations. With this change, the global blazerc can enable this feature for "blaze test". This can end up subsuming the thin_lto_linkstatic_tests_use_shared_nonlto_backends feature. However, it might be useful to keep that one as it can be the default for all blaze builds (in case anyone wants to just build and not run their tests). RELNOTES: None PiperOrigin-RevId: 193667161