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
This marks the official launch of editions, which no longer requires an --experimental_editions flag to use with supported generators. The flag can still be used for generators that don't yet explicitly support editions.
PiperOrigin-RevId: 614729247
There is no canonical rules_ruby repo today, and we don't want our fork to become one. In order to unblock inclusion of Protobuf in the bzlmod registry, we're making this a dev dependency and dropping support for Bazel/Ruby.
Fixes#14569
PiperOrigin-RevId: 584393841
This uses https://github.com/protocolbuffers/rules_ruby to fully Bazelify our ruby runtime code. The Rakefile is left in place for now and is still used by our aarch64 tests. With the current implementation ruby behaves similarly to our python wrapper, which selects whatever version is installed in the system. Future enhancements will allow for more hermetic builds via Bazel flags to pin a specific version
Closes#10525
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/10525 from mkruskal-google:rules_ruby 97fa1f70ab
PiperOrigin-RevId: 499283908
Prepare protobuf for bzlmod
Self-reference to `@com_google_protobuf` doesn't work with bzlmod.
In case this is a rule attribute, no reference is needed.
When the label is a default parameter value in a macro it needs to be wrapped with `Label` call, to relativise it correctly.
PiperOrigin-RevId: 496687786
* Fixing typos
* Revert new files that were deleted by sync script
* Fix CMake breakages
* bump upb version
* Sync from Piper @468772608
PROTOBUF_SYNC_PIPER
* Adding abseil to include path for python C++ extension
* Adding abseil linkage for python C++ extension
* Fixing linkage order
* 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
* Switch to new provider syntax instead of structs.
* Expose files via `DefaultInfo`, and use that for `py_proto_library`.
* Several changes from buildifier.
When both directories are added this results in protoc emitting a
"warning: directory does not exist.". This makes sense because when
there are no inputs from the other directory, it is also not present
n the sandbox where protoc is executed.
* 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
Bazel has switched its protobuf rules to make them use the proto
compiler in the exec configuration instead of the host configuration.
However, if rules in protobuf still use the host configuration then
multiple copies of the compiler can end up being built.
cfg="host" is deprecated in any case and being replaced with cfg="exec"
where possible.
https://docs.bazel.build/versions/master/skylark/rules.html#configurations
* 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
We may need the shell environment (potentially augmented with
`--action_env`) to invoke protoc on Windows. If protoc was built with
mingw, it probably needs .dll files in non-default locations that must be
in PATH. Previously with `--compiler=mingw-gcc`,
`bazel build //:gen_well_known_protos_java` would fail on Windows. This
CL fixes the issue.
Also we have `default_shell_env` set to True for `ProtoCompile`, this makes
the behavior consistent.
See #2933, and
585a27ad0a/proto/compiler.bzl (L130)
Envoy was experiencing failed builds due to lots of duplicate -I in the
CLI. The solution is to generally use depset() as per Starlark best
practice for this sort of thing.
Might fix other issues beyond py_proto_library, anything that depends on
proto_gen.
release notes: no
Signed-off-by: Harvey Tuch <htuch@google.com>
* [bazel] Move Java runtime/toolchains into //java
This change moves `java_library` targets from the top-level BUILD file
into `//java/{core,lite,util}` and declares `alias` targets to point to
their new locations (hence, this is not a breaking change).
This will allow users that don't use Java to stop depending on
`@rules_java` (e.g. as requested in
https://github.com/bazelbuild/rules_scala/pull/989#issuecomment-583405161).
Note that there is no intention to deprecate + remove the top-level
targets in the foreseeable future.
* Add BUILD files in //java to java_EXTRA_DIST
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.
@bazel_skylib//:lib is supposedly deprecated. The 'versions' struct in lib.bzl was committed to bazel-skylib at the same time as //lib:versions.bzl, so there should be no backward incompatibility.
Brent Shaffer
Protobuf Team Bot
Tiago Quelhas
Mike Kruskal
Thomas Van Lenten
Mike Kruskal
David L. Jones
FaBrand
Derek Perez
Adam Cozzette
Deanna Garcia
Ivo List
Xùdōng Yáng
Charles Mita
Adam Yi
Harvey Tuch
Leo
Yannic Bonenberger
Brian Wignall
Benjamin Peterson
Keith Smiley
Paul Yang
Jon Brandvein
Roger Chen
James Judd
Adam Cozzette
Feng Xiao
Ittai Zeidman
Fahrzin Hemmati
Fahrzin Hemmati
Mateusz Matejczyk