commit | a47780541536764cf56d09f78a988d6155689c7f | [log] [tgz] |
---|---|---|
author | hlopko <hlopko@google.com> | Fri May 26 11:37:28 2017 +0200 |
committer | Irina Iancu <elenairina@google.com> | Fri May 26 13:25:58 2017 +0200 |
tree | 3ec1afd6b557ac27a6bd827fcdcee51865fef69f | |
parent | 1fd27bc4d97533031401c54aa05eb75b13c6874b [diff] |
Use FeatureConfiguration to compute value of CC_FLAGS make variable 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
{Fast, Correct} - Choose two
Bazel is a build tool that builds code quickly and reliably. It is used to build the majority of Google‘s software, and thus it has been designed to handle build problems present in Google’s development environment, including:
A massive, shared code repository, in which all software is built from source. Bazel has been built for speed, using both caching and parallelism to achieve this. Bazel is critical to Google's ability to continue to scale its software development practices as the company grows.
An emphasis on automated testing and releases. Bazel has been built for correctness and reproducibility, meaning that a build performed on a continuous build machine or in a release pipeline will generate bitwise-identical outputs to those generated on a developer's machine.
Language and platform diversity. Bazel's architecture is general enough to support many different programming languages within Google, and can be used to build both client and server software targeting multiple architectures from the same underlying codebase.
Find more background about Bazel in our FAQ.