aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/genrule
Commit message (Collapse)AuthorAge
* 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-08-17 12:39:00 +0000