aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/genrule
Commit message (Collapse)AuthorAge
* AbstractAction: Use ActionInputFileCache instead of MetadataHandlerGravatar ulfjack2017-09-08
| | | | | | This is a prerequisite for merging the two interfaces. PiperOrigin-RevId: 167843789
* More BUILD file refactorings.Gravatar philwo2017-09-06
| | | | | | | | | Split collect, concurrent, vfs, windows into package-level BUILD files. Move clock classes out of "util", into their own Java package. Move CompactHashSet into its own Java package to break a dependency cycle. Give nestedset and inmemoryfs their own package-level BUILD files. PiperOrigin-RevId: 167702127
* Make Make variables from genrule.toolchains override the usual synthetic ↵Gravatar lberki2017-09-04
| | | | | | | | | host JAVA/JAVABASE attributes. Also fix a few lint warnings and move a class so that it's closer to where it's actually used. RELNOTES: None. PiperOrigin-RevId: 167501208
* Rename bazel-user-manual.html into user-manual.htmlGravatar dmarting2017-09-04
| | | | PiperOrigin-RevId: 167477112
* Allow CommandLine expansion to throw an exception.Gravatar tomlu2017-08-24
| | | | | | | | | | | | | | | | | | | This paves the way for Skylark-side compact command lines that can fail during expansion. In general, expansion happens in these scenarios: * Action execution expands the command line to execute it. This is fine since we are well equipped already to handle failing actions. * In the analysis phase we expand command lines to investigate whether we need a params file. This could be moved to the execution phase, which would have the benefit of getting params files out of the action graph and saving memory. * Key computation expands the command line. This could be fixed by allowing command lines to compute their own keys (which wouldn't try to expand the command line). This could have the benefit of being more efficient. * Extra actions expand the command line to construct the extra action proto. This could maybe be deferred to the execution phase (writing the extra action), which would also be more memory efficient. For failed key computations, we return a singleton "error" key. This means multiple actions that will fail will map to the same key. These actions will necessarily fail if executed, so we should not need to worry about these ending up in the action cache. If we do manage to make the command line compute its own keys then this will become moot in the future. RELNOTES: None PiperOrigin-RevId: 166266385
* Rename some of native declared providers according to the new naming scheme.Gravatar dslomov2017-08-21
| | | | | RELNOTES: None PiperOrigin-RevId: 165910455
* Fetch the Java-specific Make variables from the :host_jdk dependency instead ↵Gravatar lberki2017-08-18
| | | | | | | | | of the configuration in genrules. This is necessary because if one uses a java_runtime rule that has java_home="$(VAR") and VAR is set to an absolute path, BuildConfiguration won't be able to resolve VAR (since it's a Make variable and thus can't affect other Make variables), Blaze won't be able to tell that it's an absolute value and thus will prepend the package name of the java_runtime rule to it, e.g. resulting in a//foo/bar instead of /foo/bar if the java_runtime rule is in package a. RELNOTES: None. PiperOrigin-RevId: 165555251
* Move MakeVariableProvider to lib.analysisGravatar ulfjack2017-08-08
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164456961
* Move RuleConfiguredTargetFactory to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164446955
* Move AliasProvider to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164438390
* 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 a toolchains= attribute to *_binary, *_test, cc_library and extra_action ↵Gravatar lberki2017-07-14
| | | | | | | | | rules to declare which Make variables they need. The idea is that they would depend on the future java_runtime_alias / cc_toolchain_alias and similar rules and thus Bazel will know which Make variables they actually need instead of pulling in the whole BuildConfiguration and also making it possible to compute these Make variables during analysis instead of configuration creation. RELNOTES: None. PiperOrigin-RevId: 161785868
* MakeVariableProvider should be declared provider only.Gravatar dslomov2017-07-11
| | | | | RELNOTES: None. PiperOrigin-RevId: 161527470
* Update the default values for the C++ and Java late-bound attributes to the ↵Gravatar janakr2017-07-10
| | | | | | correct //tools/cpp:toolchain and //tools/jdk:jdk. PiperOrigin-RevId: 161227981
* Update SpawnAction to take an ActionEnvironmentGravatar ulfjack2017-07-05
| | | | | | | | | | Some of the callers are not using the proper one from the configuration, and are thus ignoring --action_env. Some are only using part of the configuration's action environment. I tried to carefully not change the semantics in any case. Semantic-changing changes come later. PiperOrigin-RevId: 160891204
* Rewrite the Executor/ActionExecutionContext splitGravatar ulfjack2017-06-19
| | | | | | | Move everything to ActionExecutionContext, and drop Executor whereever possible. This clarifies the API, makes it simpler to test, and simplifies the code. PiperOrigin-RevId: 159414816
* Use FeatureConfiguration to compute value of CC_FLAGS make variableGravatar hlopko2017-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | This cl introduces new action_config type for Crosstool named 'generic'. This can be used to set the value of CC_FLAGS make variable using much more expressive mechanism (action_configs + features) than previous make_variable Crosstool messages. This has been requested by the C++ LPT. However, as FeatureConfiguration needs RuleContext, CC_FLAGS cannot be computed using configuration only anymore. Also, FeatureConfiguration is C++ rules specific class, and Bazel build-base cannot depend on it. Therefore we cannot use FeatureConfiguration for ExtraActions, for example. Because it cannot be made perfect, this cl is not updating all the possible places that expand make variables but limits the scope to: * genrule (the only widely used rule that often expands make variables) * *_test (CC_FLAGS is used by Tensorflow in the 'args' attribute) * cc_rules (people sometimes set 'copts' to something like: "-DCC_STRING=\\\"$(CC)\\\" -DCC_FLAGS_STRING=\"$(CC_FLAGS)\"" The long term plan is to use Skylark C++ API to get C++ command lines, so CC_FLAGS together with this inconsistent solution will be removed. RELNOTES: CC_FLAGS can be defined using 'generic' action_config in CROSSTOOL PiperOrigin-RevId: 157202883
* Use nested sets for configured target runfiles instead of flattened lists.Gravatar Googler2017-05-26
| | | | | RELNOTES: None PiperOrigin-RevId: 157124371
* Add CC_FLAGS to the macros that pull in the CcToolchainProvider for genrulesGravatar Googler2017-05-23
| | | | | RELNOTES: Using $(CC_FLAGS) in a GenRule adds a dependency to the c++ toolchain PiperOrigin-RevId: 156770639
* Extract :cc_toolchain as constantGravatar hlopko2017-05-22
| | | | | | | | And while at it cleanup all the calls of CppHelper.getToolchain and CppHelper.getFdoSupport. RELNOTES: None. PiperOrigin-RevId: 156716291
* Remove methods from CommandLine, making it a simple argument list interface.Gravatar Googler2017-05-15
| | | | | | | * isShellCommand is now passed directly to SpawnAction * Getting the associated params file action was a test-only thing. We can pull this out of the action graph instead. PiperOrigin-RevId: 156060366
* Give RuleContext the ability to add make variables.Gravatar lberki2017-05-05
| | | | | | This CL also makes CcToolchain responsible for adding the sysroot to CC_FLAGS. PiperOrigin-RevId: 155171725
* Automated g4 rollback of commit ce33ab7a49126a513d7d5a6bc16f86154d9a85b6.Gravatar plf2017-05-03
| | | | PiperOrigin-RevId: 154931201
* Give RuleContext the ability to add Make VariablesGravatar Googler2017-04-27
| | | | | | This CL also makes CcToolchain responsible for adding the sysroot to CC_FLAGS. PiperOrigin-RevId: 154329746
* Avoid calls to NestedSetBuilder#addAll(NestedSet)Gravatar cushon2017-04-10
| | | | PiperOrigin-RevId: 152654844
* Automated g4 rollback of commit 8c41633a8700cbadd2ef219879cba305b576070e.Gravatar schmitt2017-04-10
| | | | | | | | | | | | | *** Reason for rollback *** Causes Blaze release failures. *** Original change description *** Genrules only depend on the host JDK if they have Java make variables. e.g.: cmd = "$(JAVA) foo.java ..." PiperOrigin-RevId: 152516143
* Genrules only depend on the host JDK if they have Java make variables.Gravatar Googler2017-04-06
| | | | | | e.g.: cmd = "$(JAVA) foo.java ..." PiperOrigin-RevId: 152263822
* Rename the ToolchainProvider to a more accurate name (and free up the name ↵Gravatar jcater2017-04-03
| | | | | | | | for the new ToolchainProvider). Change-Id: I3537e1ed924c598707759c4a7040d5ba00de559c PiperOrigin-RevId: 151853764
* Small documentation fix.Gravatar Googler2017-03-31
| | | | | | RELNOTES: none PiperOrigin-RevId: 151746179
* Genrules only depend on the C++ toolchain if they have C++ make variables. Gravatar Greg Estren2017-03-28
| | | | | | | | | | e.g.: cmd = "$(CC) foo.cc > $@" Fixes #2729 -- PiperOrigin-RevId: 151369889 MOS_MIGRATED_REVID=151369889
* Remove duplicate genrule documentation on base class.Gravatar John Cater2017-02-24
| | | | | | | | -- Change-Id: Ie33953add6a582368b6b0da74c478a8dd301acb4 Reviewed-on: https://cr.bazel.build/9041 PiperOrigin-RevId: 148355280 MOS_MIGRATED_REVID=148355280
* Rollback of commit 4b73e972d909bcd533f2f9940f95a00b9b73bdde.Gravatar Dmitry Lomov2017-02-17
| | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Broke tests on CI: http://ci.bazel.io/job/bazel-tests/570/ *** Original change description *** Roll forward execroot change RELNOTES[INC]: Previously, an external repository would be symlinked into the execution root at execroot/local_repo/external/remote_repo. This changes it to be at execroot/remote_repo. This may break genrules/Skylark actions that hardcode execution root paths. If this causes breakages for you, ensure that genrules are using $(location :target) to access files and Skylark rules are using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc. functions. Cust... -- PiperOrigin-RevId: 147833177 MOS_MIGRATED_REVID=147833177
* Roll forward execroot changeGravatar Kristina Chodorow2017-02-16
| | | | | | | | | | | | | | | | | RELNOTES[INC]: Previously, an external repository would be symlinked into the execution root at execroot/local_repo/external/remote_repo. This changes it to be at execroot/remote_repo. This may break genrules/Skylark actions that hardcode execution root paths. If this causes breakages for you, ensure that genrules are using $(location :target) to access files and Skylark rules are using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc. functions. Custom crosstools that hardcode external/<repo> paths will have to be updated. Issue #1262. -- PiperOrigin-RevId: 147726370 MOS_MIGRATED_REVID=147726370
* Use //third_party/protobuf:protobuf_java instead of ↵Gravatar Carmi Grushko2017-02-09
| | | | | | | | | | | | //third_party/protobuf:protobuf to refer to the Java proto runtime. (second attempt) This is the name in the upstream protobuf repo. -- PiperOrigin-RevId: 147057949 MOS_MIGRATED_REVID=147057949
* Stop retrieving CcToolChainProvider statically from hard-coded attribute ↵Gravatar Rumou Duan2017-02-08
| | | | | | | | | | ":cc_toolchain" in RuleContext, instead take the provider from users and pass it around to where it is used. This gives J2ObjcAspect the ability to specify the C++ toolchain attribute under a different name to avoid attribute conflicts with attached rules that have already declared attribute ":cc_toolchain". -- PiperOrigin-RevId: 146920294 MOS_MIGRATED_REVID=146920294
* Update GenRule to include the Cpp and Jdk toolchains and properly handleGravatar John Cater2017-02-06
| | | | | | | | expanded make variables. -- PiperOrigin-RevId: 146478427 MOS_MIGRATED_REVID=146478427
* --Gravatar John Cater2017-02-01
| | | | | PiperOrigin-RevId: 146138214 MOS_MIGRATED_REVID=146138214
* Switch to RunfilesSuppliers for communicating runfilesGravatar Michajlo Matijkiw2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | ActionSpawn/SpawnAction now deal exclusively in RunfilesSuppliers, manifests maps are no more. There is some lingering awkwardness, in particular: - Manifests still need to be tracked in some places, we can work out if this is still necessary on a case by case basis. - Skylark makes actions' runfiles available via 'resolve_command' where they are consumed by 'action'. I've updated the documentation, though the name isn't entirely accurate anymore. That being said these interfaces _are_ marked as experimental, so we _should_ be able to be flexible here. Overall, I think the benefits consolidating runfiles into suppliers, from both code cleanliness and performance perspectives (no longer needing to parse manifests), outweights the awkwardnesses. RELNOTES: resolve_command/action's input_manifest return/parameter is now list -- PiperOrigin-RevId: 145817429 MOS_MIGRATED_REVID=145817429
* Create a base implementation of GenRule that can be used by both Bazel andGravatar John Cater2017-01-30
internal Google code. -- PiperOrigin-RevId: 145795255 MOS_MIGRATED_REVID=145795255
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 17:59:16 +0000