the glob pattern `**/*.bzl` doesn't match anything there, and this is bad for `--incompatible_disallow_empty_glob`. This PR removes the offending line.
Remove redundant tags for copybara to replace labels with labels including the
repository, where there are no labels to substitute after 2f8c04c044.
PiperOrigin-RevId: 510103824
Change-Id: I9b65a6b7f9b48885aec4df5f4723273633be4860
BEGIN_PUBLIC
Copybara import of the project:
--
56e69b82484f1a9fb55d8173cc112f9f608f3581 by Fabian Meumertzheim <fabian@meumertzhe.im>:
Simplify WORKSPACE setup and update ancient deps
By removing a single unused `bzl_library` target, rules_cc no longer has
any dependencies that would need to be loaded by a dependency macro. The
existing macro is made a no-op.
The few needed Bazel Federation dependencies are inlined and, in the
case of bazel_skylib and abseil-py, updated to modern versions.
Also reorders `WORKSPACE` to list direct dependencies first and keeps
`MODULE.bazel` in sync with the dependency versions used in WORKSPACE.
The `ubuntu1604` CI pipeline is removed as the version of Python used by
it is no longer supported and the distribution is EOL. Instead, a new
pipeline is added to check the Bzlmod build.
END_PUBLIC
COPYBARA_INTEGRATE_REVIEW=https://github.com/bazelbuild/rules_cc/pull/165 from fmeum:fix-workspace-module 56e69b82484f1a9fb55d8173cc112f9f608f3581
PiperOrigin-RevId: 501245864
Change-Id: Ib71ad910705807a00929a76774387a38d2da0f9f
*** Reason for rollback ***
Broke a test
*** Original change description ***
The auto-configured toolchains provided by Bazel itself have diverged heavily from the version maintained in this repo. There is no need to maintain this duplication until Starlarkification has progressed succiciently for rules_cc to be the source of truth for them.
This is particularly relevant for Bzlmod, which currently uses the toolchains defined in rules_cc. As a result, Bazel C++ builds will use subtly different toolchains depending on whether --enable_bzlmod is used or not. This is fixed...
***
PiperOrigin-RevId: 501228335
Change-Id: I858dc3ea44df7ae70b5603f6dc2e082b4540c42a
This is particularly relevant for Bzlmod, which currently uses the toolchains defined in rules_cc. As a result, Bazel C++ builds will use subtly different toolchains depending on whether --enable_bzlmod is used or not. This is fixed by loading toolchain detection logic from @bazel_tools in the module extension.
Closes #163
PiperOrigin-RevId: 501199523
Change-Id: I01f263d37495d0c5dd070c8a32945898d1d639c5
They are now part of the bazelbuild/bazel repository.
Copies buildifier changes contributed by Keith in https://github.com/bazelbuild/rules_cc/pull/128
RELNOTES:none
PiperOrigin-RevId: 435312636
Change-Id: I4d5d2f58d90026c0cdfb5c0a90709de7c28c6ccd
- bazel presumed a trailing space in `clang-cl -v` output that is
no longer present in the 11.0.0 release, resulting in an injected newline
Co-authored-by: Sunjay Bhatia <sunjayb@vmware.com>
Co-authored-by: William A Rowe Jr <wrowe@vmware.com>
Signed-off-by: Sunjay Bhatia <sunjayb@vmware.com>
Signed-off-by: William A Rowe Jr <wrowe@vmware.com>
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
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
For now we will restrict allowed exports to the same package. At the same time
static_deps should be used to take into account what should be linked into a
shared library.
RELNOTES:none
PiperOrigin-RevId: 294668451
Change-Id: Ia087519106983bfa9a980e471d3102ab391a53eb
We're working on removing C++ toolchain autoconfiguration logic out of Bazel,
and moving towards using rules_cc repository for it. Some bzl files will no
longer be available through bazel/tools/cpp/*, but through
@rules_cc/cc/*.
RELNOTES: None.
PiperOrigin-RevId: 279935457
Change-Id: I3bae259548dacc5c6789efe0f27dd07738c1057c
Labels in toolchains attribute need to include the repository, otherwise the resolution won't work.
RELNOTES: None.
PiperOrigin-RevId: 279347045
Change-Id: Iba1eb8bb677771e2c089ab6bc1b5e019c4da434e
Fixes:
* Enabled buildifier on the Bazel CI again
* Added Skydocs where missing
* Moved public files out of .../private/... (e.g. cc_toolchain_config_lib.bzl)
* Reformatted
* Removed unused loads
* Using relative labels for cc_configure related files
* Added development dependency on rules_proto
* they're not in the federation yet, so hand rolling in rules_cc's WORKSPACE file
* Added development dependency on rules_python (from federation)
* Cleaned up copybara (notable change - not using @rules_cc in labels inside rules_cc repo)
* Made cc_flags_supplier usable internally
* Moved load statements to the top of the bzl file
* Moved runfiles to the tools directory
* Unified toolchain_utils.bzl and find_cc_toolchain.bzl
RELNOTES: None.
PiperOrigin-RevId: 276479521
Change-Id: I3196896061fa2ee61a3efb130c214d288782066a
Googler