* 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 commit upgrades upb to the latest commit on its 21.x branch to pull
in this fix: https://github.com/protocolbuffers/upb/pull/717 I also
updated CHANGES.txt to reflect that fix and one other Bazel change.
* Eliminated git_repository() in favor of HTTP archives.
Also factored out logic for github archives into its own macro.
* Sorted entries and ran buildifier.
* Removed the import of git_repository.
* WIP.
* Restore deleted __init__.py files.
* Updated version of upb.
* Moved upb from a submodule to a Bazel dep.
* Updated to new upb which can tolerate missing system_python.
* Updated to a new upb.
This is the most recent Abseil LTS branch, from November 2021. We do not
yet use Abseil for anything, but this change will make it possible to
start using it in Bazel when we're ready.
* Creates a protoc release zip
Mimics what we're doing manually today but powered by Bazel.
* don't special case this.
* Addressing feedback.
* adding comment about _cc_toolchain
* Use repo-relative labels wherever possible
The label `@com_google_protobuf//:foo` within the protobuf repo is often synonymous with just `//:foo`. We should prefer the latter as it allows us to use a shorter name for the module in the Bazel Central Registry (so just "protobuf" instead of "com_google_protobuf").
Note that the semantics can be subtle: in a macro, plain strings are anchored to the *calling* repo, so if we just use `//:foo` as the default value of a macro argument, it will be resolved to `@myrepo//:foo` if the macro is called from the repo `@myrepo`. In this case, it's necessary to directly call the `Label()` constructor to anchor the string label to the repo where the .bzl file lives.
See https://github.com/bazelbuild/bazel-central-registry/pull/28#issuecomment-954741081 for a bit more context.
* fix protobuf_deps.bzl
This commit removes the use of bind() since that function goes against
Bazel best practices:
https://docs.bazel.build/versions/main/external.html#repository-rules-1
The bind() function basically maps a dependency into //external, but
there is no good reason to do this. By mapping dependencies into
//external and relying on this in our own BUILD files, we're forcing
projects that depend on us to do the same. The one bind() call that I
did leave in place was //:python_headers. This one seems to be doing
something complicated I don't fully understand, and I don't want to risk
breaking it.
This change also moves our list of required Maven artifacts into a
constant in protobuf_deps.bzl. This way, projects that depend on us can
refer to this list when they invoke maven_install() and automatically
pull in all the necesary dependencies.
This fixes#9132.
other bazel libraries (e.g. rules_docker 0.15.0) require rules_python 0.1.0
or above. running protobuf_deps() before importing rules_docker
will lead to errors.
upgrading rules_python fixes this problem.
* Protobuf Java/Core Tests running w/ Bazel.
Also integrates rules_jvm_external and migrates existing maven deps
in place.
* Add test_suite target that maps to rule name.
* Lite tests passing in Bazel
* util tests passing with Bazel.
* Add conformance and build testing to //java:core
* Cleanup bzl style and lock down access to failure lists.
* Adding Java Lite conformance tests.
* rm newline
* parameterize conformance_test
This makes usage of failure lists more explicit.
* restrict visibility more for newly added libs and fix formatting.
* fix formatting and visibility.
* move testing.bzl to an internal package.
* fix file formatting.
* moving conformance_test to internal.bzl
The previous version does not mark the `toolchain_type` as public,
meaning that users of a CC toolchain using
`@rules_cc//cc:toolchain_type` will get build errors along the lines of
```
ERROR:
.../local_config_cc_toolchains/BUILD.bazel:18:1:
in toolchain rule
@local_config_cc_toolchains//:cc-toolchain-armeabi-v7a: alias
'@rules_cc//cc:toolchain_type' referring to target
'@bazel_tools//tools/cpp:toolchain_type' is not visible from target
'@local_config_cc_toolchains//:cc-toolchain-armeabi-v7a'. Check the
visibility declaration of the former target if you think the dependency
is legitimate
```
Mike Kruskal
Deanna Garcia
Sandy Zhang
Adam Cozzette
Joshua Haberman
Xùdōng Yáng
zhangskz
David L. Jones
Mike Kruskal
Elliotte Rusty Harold
Derek Perez
Dirk Boye
c-parsons
Dor
Keith Smiley
Andreas Herrmann
listonjesse
Yannic