This is phase 2 of of the switch to toolchain transitions. See https://github.com/bazelbuild/bazel/issues/11584 for details.
PiperOrigin-RevId: 334808134
Change-Id: Ie198b07359d4fd45368755c4cc223e397f0e8fb0
--//examples:incompatible_link_once=False[default = False]
When True, it will be an error to link the same library more than once
unless it has the tag LINKABLE_MORE_THAN_ONCE
--//examples:experimental_debug=True[default = False]
When True, it will generate files listing the exports of each cc_shared_library
and which libraries are linked to it statically.
RELNOTES:none
PiperOrigin-RevId: 311323625
Change-Id: I340cc71965650f7c9dd7ef7fb9656da362021527
Changes in this CL:
1. 'exports' attribute renamed to roots
2. Removed restrictions for exporting a rule in a different repository
3. Kept restrictions for rules in the same repository but not in the same
package or subpackages
4. To get around restrictions, instead of the exported_by tag, one can use the
cc_shared_library_permissions rule
5. Added exports_filter that will match libraries in the transitive closure of
a root. Anything matched by the exports_filter will also be exported.
Restrictions as in 4. still apply.
RELNOTES:none
PiperOrigin-RevId: 310547916
Change-Id: I32d8e0d4dd4bcc9c9e92f4ff3c5b2a01564c31b2
This change adds an optional field to the C++ crosstool proto that
allows configuring the origin tool_path is relative to.
For now, the origin can be one of the following:
- CROSSTOOL_PACKAGE: If tool_path is a relative path, it's assumed to
be relative to the package of the crosstool top.
- FILESYSTEM_ROOT: tool_path is an absolute path. This is checked by
Bazel.
- WORKSPACE_ROOT: tool_path must be a relative path and is assumed to
be relative to the exec-root of the workspace (similar to other
executables).
Updates bazelbuild/bazel#8438
Closes #10967.
PiperOrigin-RevId: 310142352
Change-Id: If6316ffa5d7d2713b197840b4aafb2f0cdbb0b96
We were returning false when checking whether //foo:bar is under
//:__subpackages__
RELNOTES:none
PiperOrigin-RevId: 307808962
Change-Id: I080e4c239b75c188dae8af89f4b38aa935d92b0d
1. Don't pop from the front of the list being iterated on
2. Don't visit the same node_label more than once
RELNOTES:none
PiperOrigin-RevId: 307610981
Change-Id: I9b35a27a1bdabafbe290d1ff23eeb4659b07d554
This allows setting GCOV on the command line to overwrite the default setting, which points to /usr/bin/gcov. In order to use this, you also need to disable the gcov coverage feature and enable the llvm coverage feature instead. The full command-line looks like this:
GCOV=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/llvm-profdata bazel coverage --features=llvm_coverage_map_format --features=-gcc_coverage_map_format //cpp:test
Progress on #10457.
Original change by ulfjack
RELNOTES: None.
PiperOrigin-RevId: 300583709
Change-Id: Ibeda8469db6750fc9fc3bba60e19118a2e482ed8
Default linker flags contains flags like -lstdc++ which should come after the
user libraries. The library flags are removed from default linker flags and added to link_libs instead which comes after user libraries.
See #9254
Incompatible flag bug: https://github.com/bazelbuild/bazel/issues/10905
I introduce a new method to repositories ctx that allows checking the value of a Starlark semantic option from a repository rule.
RELNOTES:none
PiperOrigin-RevId: 299336105
Change-Id: I81b9ee0c72e2a2252b406f1c584997389a530e40
The syntax now matches visibility's. This is less confusing than
before, we now have:
- targets like //foo, //foo:foo or //foo:bar
- same package match like //foo:__pkg__
- subpackages like //foo:__subpackages__
RELNOTES:none
PiperOrigin-RevId: 298598757
Change-Id: I6d02cf03c3c67d78998dda27a6529d53d0ef2708
This function is meant to be used for the tag containing exported_by.
RELNOTES:none
PiperOrigin-RevId: 298568236
Change-Id: Ia7b039d1764a3b79a3a0cc3f7f68a8eb17e6f0d5
Libraries are tagged with LINKABLE_MORE_THAN_ONCE can be linked into more than
one shared library and not give an error.
RELNOTES:none
PiperOrigin-RevId: 297352891
Change-Id: Id32b5c341bfd9d5906d67216773e82b0d8b63faf
The --experimental_cc_shared_library used to block API methods
that were needed in the cc_shared_library implementation. However, these
methods have been made freely available to everyone so that people can start
migrating to the new API.
With that change, the cc_shared_library has become free to use unless we block
it with the method call added in this CL.
RELNOTES:none
PiperOrigin-RevId: 297127873
Change-Id: I103fe7724b9c4956a5bee8bed0f6d074a6e453f1
The same command line can be obtained with the attributes
user_link_flags and additional_linker_inputs used together.
In the first design iterations of cc_shared_library it was decided to have the
visibility_file attribute so that a cc_shared_library could be used for many
different platforms smoothly.
For this to work the visibility file would have had to be platform neutral and
then Bazel would have had to write a visibility file specific for each
platform, e.g. the version script for Unix and the exports map for Windows.
However, in the last approved design it was decided not to have Bazel get in
the business of understanding symbols and automatically writing export maps.
With this approach, it then became necessary for people to use selects() in the
visibility_file attribute depending on the platform that the file was for.
Since we have added a new way to add files with the attribute
additional_linker_inputs and we need selects() anyway,
it doesn't make sense to keep the visibility_file attribute, the
same can be achieved with selects in the other two attributes mentioned.
In any case, if this can be made more ergonomic in the future, we can do so.
However, removing this attribute after flipping the experimental flag would be
an incompatible change.
PiperOrigin-RevId: 295925566
Change-Id: I52733e006f4b0f79f50380e89fc2eeae58dbad4d
Before dynamic lib dependencies of cc_shared_library were always linked at the
end. Now for creating the command line we respect the topological order that
would be given when getting the libs from the dependency graph created by the
cc_libraries.
RELNOTES:none
PiperOrigin-RevId: 295676824
Change-Id: I327a0e10920f18fed234dd5835e54cab75a0d428
Benjamin Peterson