| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161527470
|
|
|
|
|
|
| |
correct //tools/cpp:toolchain and //tools/jdk:jdk.
PiperOrigin-RevId: 161227981
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 157124371
|
|
|
|
|
| |
RELNOTES: Using $(CC_FLAGS) in a GenRule adds a dependency to the c++ toolchain
PiperOrigin-RevId: 156770639
|
|
|
|
|
|
|
|
| |
And while at it cleanup all the calls of CppHelper.getToolchain and
CppHelper.getFdoSupport.
RELNOTES: None.
PiperOrigin-RevId: 156716291
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
| |
This CL also makes CcToolchain responsible for adding the sysroot to CC_FLAGS.
PiperOrigin-RevId: 155171725
|
|
|
|
| |
PiperOrigin-RevId: 154931201
|
|
|
|
|
|
| |
This CL also makes CcToolchain responsible for adding the sysroot to CC_FLAGS.
PiperOrigin-RevId: 154329746
|
|
|
|
| |
PiperOrigin-RevId: 152654844
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
| |
e.g.: cmd = "$(JAVA) foo.java ..."
PiperOrigin-RevId: 152263822
|
|
|
|
|
|
|
|
| |
for the new ToolchainProvider).
Change-Id: I3537e1ed924c598707759c4a7040d5ba00de559c
PiperOrigin-RevId: 151853764
|
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 151746179
|
|
|
|
|
|
|
|
|
|
| |
e.g.: cmd = "$(CC) foo.cc > $@"
Fixes #2729
--
PiperOrigin-RevId: 151369889
MOS_MIGRATED_REVID=151369889
|
|
|
|
|
|
|
|
| |
--
Change-Id: Ie33953add6a582368b6b0da74c478a8dd301acb4
Reviewed-on: https://cr.bazel.build/9041
PiperOrigin-RevId: 148355280
MOS_MIGRATED_REVID=148355280
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
//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
|
|
|
|
|
|
|
|
|
|
| |
":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
|
|
|
|
|
|
|
|
| |
expanded make variables.
--
PiperOrigin-RevId: 146478427
MOS_MIGRATED_REVID=146478427
|
|
|
|
|
| |
PiperOrigin-RevId: 146138214
MOS_MIGRATED_REVID=146138214
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
internal Google code.
--
PiperOrigin-RevId: 145795255
MOS_MIGRATED_REVID=145795255
|