protobuf

Commit Graph

Author	SHA1	Message	Date
Protobuf Team Bot	c820dd0ca6	Upgrade rules_cc 0.0.16 and rules_java 8.3.1 Both versions are again compatible with WORKSPACE mode on Bazel 8. The version also extends the compatibility down to Bazel 6. Add repo_name = "com_google_protobuf" to examples/MODULE.bazel. Bazel 6,7,and 8 (in WORKSPACE mode) still expect this is the name of the repo. (Default value of --proto_compiler flag). There's no way to change this without breaking compatibility with WORKSPACE mode. Remove local_repository(name = protobuf) from WORKSPACE. The repository is now consistently called com_google_protobuf in both WORKSPACE and Bzlmod mode. Rename uses of @protobuf to @com_google_protobuf. PiperOrigin-RevId: 695579489	2 weeks ago
Protobuf Team Bot	cb1f518b4e	Fix mixing rules from builtins and protobuf The rules in protobuf and built-in Bazel don't mix well. Different aspects may cause actions conflicts. The safest way is to use built-in rules whenever they are still present. proto_library should be safe, because it's not using an aspect. py_proto_library never had a built-in implementation, so it's also safe. This still makes it possible to use the rules on Bazel 7, but only with --incompatible_autoload_externally enabled. PiperOrigin-RevId: 678446311	2 months ago
Protobuf Team Bot	8257c4469d	Copy py_proto_library from rules_python to protobuf https://github.com/bazelbuild/rules_python/blob/main/python/private/proto/py_proto_library.bzl Contributors: d96214f tpudlik@google.com Wed Nov 15 02:48:06 2023 -0800 fix: py_proto_library: transitive strip_import_prefix (#1558) 85e50d2 tpudlik@gmail.com Tue Nov 14 06:04:59 2023 -0800 fix: py_proto_library: append to PYTHONPATH less (#1553) bee35ef zplin@uber.com Wed Oct 11 20:59:34 2023 -0700 fix: allowing to import code generated from proto with strip_import_prefix (#1406) 1a333ce ilist@google.com Tue Jun 20 19:36:39 2023 +0200 fix: plugin_output in py_proto_library rule (#1280) 6905e63 ignas.anikevicius@woven-planet.global Sat Feb 11 14:02:33 2023 +0900 fix: make py_proto_library respect PyInfo imports (#1046) 0d3c4f7 ilist@google.com Wed Jan 18 23:15:52 2023 +0000 Implement py_proto_library (#832) PiperOrigin-RevId: 623401031	8 months ago
Protobuf Team Bot	21d75f861c	Remove references to rules_proto They are not needed after the rules are move into protobuf repo. Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo. PiperOrigin-RevId: 622176865	8 months ago
Alex Eagle	71e4061ace	feat: test bzlmod usage on CI (#16319 ) Closes #16319 COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16319 from protocolbuffers:bcr `d66845cfcb` PiperOrigin-RevId: 619939078	8 months ago
aiuto	3ab1276bbb	Update Bazel references to rules_pkg to the supported file locations. (#15780 ) WIP: I want to see this pass CI first. Fixes: #15779 3 scripted transforms: ``` -load("@rules_pkg//:mappings.bzl", ...) +load("@rules_pkg//pkg:mappings.bzl", ...) ``` ``` -load("@rules_pkg//:pkg.bzl", "pkg_tar") +load("@rules_pkg//pkg:tar.bzl", "pkg_tar") ``` ``` -load("@rules_pkg//:pkg.bzl", "pkg_zip") +load("@rules_pkg//pkg:zip.bzl", "pkg_zip") ``` Closes #15780 COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/15780 from aiuto:rules_pkg `a630276341` PiperOrigin-RevId: 606641398	10 months ago
Adam Cozzette	a7b0421c78	Breaking change: make protobuf comply with the C++ layering check This check enforces that each C++ build target has the correct dependencies for all headers that it includes. We have many targets that were not correct with respect to this check, so I fixed them up. I also cleaned up the C++ targets related to the well-known types. I created a cc_proto_library() target for each one and removed the :wkt_cc_protos target, since this was necessary to satisfy the layering check. I deleted the //src/google/protobuf:protobuf_nowkt target and deprecated :protobuf_nowkt, because the distinction between the :protobuf and :protobuf_nowkt targets was not really correct. Neither one exposed the headers for the well-known types in a way that was valid with respect to the layering check, and the idea of bundling all the well-known types together is not idiomatic in Bazel anyway. This is a breaking change, because the //:protobuf target no longer bundles the well-known types. From now on they should be accessed through the new //:*_cc_proto aliases in our top-level package. I renamed the :port_def target to :port, which simplifies things a bit by matching our internal name. The original motivation for this change was that to move utf8_range onto our CI infrastructure, we needed to make its dependency rules_fuzzing compatible with Bazel 6. The rules_fuzzing project builds with the layering check, and I found that the process of upgrading it to Bazel 6 made it take a dependency on protobuf, which caused it to break due to layering violations. I was able to work around this, but it would still be nice to comply with the layering check so that we don't have to worry about this kind of thing in the future. PiperOrigin-RevId: 595516736	11 months ago
Joshua Haberman	5ddb1fc609	Remove ODR violation from WKT codegen (#12406 ) (#12419 ) * Remove ODR violation from WKT codegen (#12406) Closes #12406 COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12406 from mkruskal-google:wkt `1c6748e6aa` PiperOrigin-RevId: 522418175 * Removed legacy target. --------- Co-authored-by: Mike Kruskal <mkruskal@google.com>	2 years ago
Mike Kruskal	f51923041d	Remove ODR violation from WKT codegen (#12406 ) Closes #12406 COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12406 from mkruskal-google:wkt `1c6748e6aa` PiperOrigin-RevId: 522418175	2 years ago
David L. Jones	95da0ba5b4	Rename all BUILD files to BUILD.bazel (#9892 ) This avoids conflicting names in a couple of cases. 1. Within google, we want to sync files but not name them BUILD (since the structure doesn't match). 2. On case-insensitive filesystems, `build` may be used for a build directory. Naming `BUILD.bazel` avoids potentioal conflicts.	3 years ago
Joshua Haberman	dc4aad931e	Sync from Piper @444600173 PROTOBUF_SYNC_PIPER	3 years ago
David L. Jones	d76f8c868c	Add source distribution packaging rules (#9835 ) This change adds `rules_pkg`-based targets that will produce source distribution archives, similar to `make dist`. These rules produce nearly the same outputs as `make dist`. However, there are some differences and caveats: 1. The outputs do not contain vendored googletest sources. 2. You have to run `autogen.sh` before `blaze build pkg:all`. This produces several autotools-related files directly into the source tree. 3. The output .zip files do not have a directory prefix like `protobuf-3.20.1-rc-1` (this will be addressed after [Substitute package variables in `pkg_zip#package_dir`. bazelbuild/rules_pkg#577](https://github.com/bazelbuild/rules_pkg/pull/577); the tar files do have this prefix, though.) 4. One file is missing from the archives, which is produced during the `make` build: benchmarks/gogo/cpp_no_group/cpp_benchmark.cc 5. In several places, I have explicitly excluded some files that are not in the autotools distribution outputs. I think most of those files should probably be included, but for now, I'm aiming for parity with `make dist`. These are marked with comments, so it should be easy to clean them up later.	3 years ago
listonjesse	2ae7cf0e03	Auxillary -> Auxiliary	5 years ago
Yannic Bonenberger	d2d6ff51a8	[bazel] Load python rules from @rules_python	5 years ago
Yannic Bonenberger	bf0c69e130	[bazel] Add fixes for --incompatible_load_{cc,java,proto}_rules_from_bzl (Part 2) This change adds the required loads to examples and zlib. For full compatibility with --incompatible_load_{cc,java,proto}_rules_from_bzl, we will need to roll gtest to a newer version.	5 years ago
Feng Xiao	74bf45f379	Add bazel support for examples. The example utilizes native bazel rules (proto_library, cc_proto_library, java_proto_library, java_lite_proto_library) to show how easy it is to build protobuf with bazel's native support. It also makes use of well known types which was not possible until the latest bazel 0.5.4 release and https://github.com/google/protobuf/pull/3594 .	7 years ago

9 Commits (ae488a016acd5176db6667024a620ec3dacab75f)