| commit | a2770334ea3f3111026eb3e1368586921468710c | [log] [tgz] |
|---|---|---|
| author | Michael Staib <mstaib@google.com> | Fri Jul 15 20:00:39 2016 +0000 |
| committer | Yun Peng <pcloudy@google.com> | Mon Jul 18 10:44:02 2016 +0000 |
| tree | fac21caba6f82c05c3a5bd496b39a1cd0b610fa8 | |
| parent | bdc2ecbb1b415161c45359d612ec60fa219c45fb [diff] |
Stop input and output of cc_library from clobbering each other.
Before this change:
Any given cc_library can only contribute one library with a given name to
targets which depend on it. If an input library has the same name as the
cc_library which it is an input to, the decision of which to use is based
on the link mode. e.g.,
cc_library(
name = "foo",
srcs = ["foo.c", "libfoo.so"],
)
will only contribute libfoo.a (a static library containing foo.o) in static mode,
while it will only contribute libfoo.so (the precompiled shared library) in dynamic
mode.
This change alters cc_library's behavior in this case:
* If libfoo.a would be empty (i.e., there are no linkable sources), then
this is allowed. The libfoo.so from srcs is simply passed through. (Previously,
the empty libfoo.a would be forwarded.)
* Otherwise, this is an error.
In the case where there are multiple libraries in the srcs with the same
library identifier (lib[name].[a|so|lo]), cc_library will still choose one
based on the link mode. This behavior has not changed.
Similarly, cc_library will still choose one of its own outputs based on the
link mode. That behavior has not changed either.
RELNOTES[INC]: It is now an error to include a precompiled library (.a, .lo, .so)
in a cc_library which would generate a library with the same name
(e.g., libfoo.so in cc_library foo) if that library also contains other linkable
sources.
--
MOS_MIGRATED_REVID=127569615
{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.