It looks like Bazel 6.0 changed the stringification of Label objects:
b1113f801d
That is causing some problems for our staleness test, since different
Bazel versions get different results. This CL fixes the problem by
tweaking the logic so that we explicitly format the label string.
PiperOrigin-RevId: 496790722
To allow checked-in and generated versions of the well-known type
generated code to coexist in the repo, we have to give the checked-in
versions a long file path (e.g.
//src/google/protobuf:wkt/google/protobuf/any.pb.cc). However, this path
inadvertently leaked into the generated file_lists.cmake file, so this
commit corrects that problem.
* Upgrade upb to latest head
My motivation for this is that I plan to make use of upb's
staleness_test() macro, which was recently renamed
(protocolbuffers/upb#810
An error occurred
).
* Add a staleness test for src/file_lists.cmake
This test is tagged "manual", because ordinarily no one should be
directly running this test. If we were to run this test regularly during
development then we would expect it to fail occasionally, because
file_lists.cmake will sometimes be temporarily stale until it is
auto-updated by our post-merge GitHub action. We want to run this test
nightly just as a safeguard to alert us if anything ever goes wrong with
the auto-update.
* Bazelfying conformance tests
Adding infrastructure to "Bazelify" languages other than Java and C++
* Delete benchmarks for languages supported by other repositories
* Bazelfying benchmark tests
* Bazelfying python
Use upb's system python rule instead of branching tensorflow
* Bazelfying Ruby
* Bazelfying C#
* Bazelfying Objective-c
* Bazelfying Kokoro mac builds
* Bazelfying Kokoro linux builds
* Deleting all deprecated files from autotools cleanup
This boils down to Makefile.am and tests.sh and all of their remaining references
* Cleanup after PR reorganizing
- Enable 32 bit tests
- Move conformance tests back
- Use select statements to select alternate runtimes
- Add internal prefixes to proto library macros
* Updating READMEs to use bazel instead of autotools.
* Bazelfying Kokoro release builds
* First round of review fixes
* Second round of review fixes
* Third round of review fixes
* Filtering out conformance tests from Bazel on Windows (b/241484899)
* Add version metadata that was previously scraped from configure.ac
* fixing typo from previous fix
* Adding ruby version tests
* Bumping pinned upb version, and adding tests to python CI
This change largely moves internal logic that creates the the `CcFileList` provider from `build_systems.bzl` to `cc_dist_library.bzl`.
There are also some associated changes to the particular `cc_dist_library` targets, since the output didn't really make sense after previous BUILD.bazel refactoring. There is also a target now for `libprotoc`.
- Add back benchmarks/datasets/BUILD.bazel to dist archive
- Change dist/build_systems.bzl to be compatible with Bazel 4.0.0.
After this, most builds can use //..., with one exception: non-Mac environments must also exclude objectivec:
`bazel build -- //... -//objectivec/...`
This adds logic to generate files with lists of files in cmake and automake syntax. This will allow Bazel to serve as the single Source of Truth for library sources, with cmake and automake using Bazel-derived definitions.
The definition files are not yet generated or checked in, but that will be a fairly straightforward set of follow-up changes.
Protobuf Team Bot
aiuto
Sandy Zhang
Adam Cozzette
Mike Kruskal
David L. Jones