- 08 Jan, 2020 1 commit
-
-
Brian Wignall authored
Uses https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines to find likely typos, with https://github.com/bwignall/typochecker to help automate the checking.
-
- 06 Aug, 2019 1 commit
-
-
Yannic Bonenberger authored
-
- 29 Jul, 2019 1 commit
-
-
Yannic Bonenberger authored
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.
-
- 12 Jun, 2019 2 commits
-
-
Benjamin Peterson authored
As a followup to ca3ead77, treat plugin executables as well as protoc as host tools.
-
Keith Smiley authored
This fixes compatibility with bazel when passing `--incompatible_no_support_tools_in_action_inputs` which will be flipped in an upcoming release.
-
- 06 Jun, 2019 1 commit
-
-
Benjamin Peterson authored
As a followup to ca3ead77, treat plugin executables as well as protoc as host tools.
-
- 28 May, 2019 1 commit
-
-
Keith Smiley authored
This fixes compatibility with bazel when passing `--incompatible_no_support_tools_in_action_inputs` which will be flipped in an upcoming release.
-
- 15 Dec, 2018 1 commit
-
-
Paul Yang authored
* Down-integrate internal changes * Update generated code for php, objc and csharp. * Add missing dependency in conformance_php
-
- 16 Nov, 2018 1 commit
-
-
Jon Brandvein authored
* Migrate to new `ctx.actions` API This allows building with --incompatible_new_actions_api. * Fix typo
-
- 03 Nov, 2018 1 commit
-
-
Roger Chen authored
@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.
-
- 15 Aug, 2018 1 commit
-
-
James Judd authored
This removes the need for --incompatible_disable_deprecated_attr_params when using Protobuf
-
- 21 May, 2018 1 commit
-
-
Ittai Zeidman authored
-
- 07 May, 2018 6 commits
-
-
Fahrzin Hemmati authored
-
Fahrzin Hemmati authored
-
Fahrzin Hemmati authored
-
Fahrzin Hemmati authored
-
Fahrzin Hemmati authored
-
Fahrzin Hemmati authored
-
- 11 Mar, 2018 1 commit
-
-
Mateusz Matejczyk authored
Start outputting missing *_pb2_grpc.py files when use_grpc_plugin is set to True for py_proto_library.
-
- 09 Mar, 2018 1 commit
-
-
James O'Kane authored
@com_google_protobuf prefixed versions. This allows them to work in 3rd party repositories. Fix a bad visibility rule. :hidden does not exist, but :private does.
-
- 12 Jan, 2018 1 commit
-
-
Jingwen Chen authored
-
- 04 Dec, 2017 1 commit
-
-
Fahrzin Hemmati authored
-
- 07 Aug, 2017 2 commits
-
-
Vladimir Moskva authored
-
Vladimir Moskva authored
-
- 03 Apr, 2017 1 commit
-
-
Marco A. Harrendorf authored
I am adding default shell environment, so that protobuf compilation makes use of set LD_LIBRARY_PATH and so on. In this way, also non-default gcc installations (e.g. not in /usr/lib) can be used to compile protobuf. This would fix the following issue: https://github.com/bazelbuild/bazel/issues/2515
-
- 08 Feb, 2017 1 commit
-
-
cgrushko authored
That is, Bazel can now build protobuf when the latter resides in a subdirectory of a project.
-
- 25 Jan, 2017 1 commit
-
-
Kristina Chodorow authored
Bazel is changing the way the execution root is organized (see https://github.com/bazelbuild/bazel/issues/1681 for details) and this updates the protobuf path logic to work with both old and new versions of Bazel.
-
- 16 Dec, 2016 1 commit
-
-
Yunlong Liu authored
-
- 22 Nov, 2016 1 commit
-
-
Wiktor Tomczak authored
-
- 18 Nov, 2016 1 commit
-
-
Adam Cozzette authored
-
- 12 Oct, 2016 1 commit
-
-
Florian Weikert authored
ctx.executable.plugin must be in the inputs of protoc's action when using a plugin, otherwise the action will fail. This bug has been hidden by a bug in Bazel: for every ctx.action, Bazel used to automatically add the runfiles of all executable inputs of the RULE instead of using the inputs of the specific ACTION. Consequently, we could get away with underspecifying the inputs of the action.
-
- 09 Sep, 2016 1 commit
-
-
Vladimir Moskva authored
Global variable HOST_CFG is deprecated and will not be supported soon.
-
- 15 Aug, 2016 1 commit
-
-
Andreas Bergmeier authored
Need to expose generated protobuf C++ headers so they can actually be accessed from other libraries.
-
- 01 Jun, 2016 1 commit
-
-
Yuki Yugui Sonoda authored
It helps users to support their own plugins in a manner consistent to cc_proto_library and py_proto_libary in their skylark rules
-
- 26 May, 2016 1 commit
-
-
David Z. Chen authored
Users often encounter a Python import error when trying to build Python protos if protobuf is installed locally on the machine. In this case, Python ends up looking in the wrong directory when importing files (see bazelbuild/bazel#1209 and tensorflow/tensorflow#2021). It seems that the problem is caused by Python getting confused when there are Python source files that are meant to be part of the same package but are in separate directories. Prior to #1233, the Bazel build setup would copy the Python runtime sources and all generated sources for the builtin protos into the root directory (assuming that the protobuf tree is vendored in a google/protobuf directory). With #1233, the two sets of sources are kept in their respective directories but both `src/` and `python/` are added to the `PYTHONPATH` using the new `imports` attribute of the Bazel Python rules. However, both the runtime sources and the generated sources are under the same package: `google.protobuf`, causing Python to become confused when trying to import modules that are in the other directory. This patch adds a workaround to the Bazel build to add a modified version of the original `internal_copied_filegroup` macro to copy the `.proto` files under `src/` to `python/` before building the `py_proto_library` targets for the builtin protos. This ensures that the generated sources for the builtin protos will be in the same directory as the corresponding runtime sources. This patch was tested with the following: * All Python tests in protobuf * All Python tests in tensorflow * All tests in [Skydoc](https://github.com/bazelbuild/skydoc) * Importing protobuf as `//google/protobuf` * Importing and binding targets under `//external` * Importing protobuf as `//third_party/protobuf`
-
- 10 Mar, 2016 1 commit
-
-
Steven Parkes authored
-
- 25 Feb, 2016 2 commits
-
-
David Z. Chen authored
This change makes use of new imports attribute for Bazel's Python rules, which enable adding directories to the PYTHONPATH. This allows us to remove the hack for building protobuf's Python support with Bazel and now allows projects to include protobuf using a Bazel external repository rather than requiring it to be imported directly into the source tree as //google/protobuf. This change also updates the protobuf BUILD file to use a named repository, @python//, for including Python headers rather than //util/python. This allows projects to specify their own package for Python headers when including protobuf with an external repository. Fixes #1230
-
Manjunath Kudlur authored
grpc C++ plugin generates additional files, namely .grpc.pb.cc and .grpc.pb.h. Adding these files to the outs of the _proto_gen rule, so dependents don't complain about undeclared inclusions. Also, compiling the .grpc.pb.cc requires additional header files from the grpc library, so added //external:grpc_lib to the deps of the cc_library. Clients are expected to declare that in their bazel WORKSPACE, pointing it to @grpc//:grpc++{_unsecure}.
-
- 22 Feb, 2016 1 commit
-
-
Manjunath Kudlur authored
cc_proto_library now supports use_grpc_plugin flag that passes --plugin=protoc-gen-grpc=grpc_cpp_plugin to protoc compiler invocation. grpc_cpp_plugin is assumed to be present as //external:grpc_cpp_plugin, so clients can setup their WORKSPACE files appropriately to point to grpc location using bind.
-
- 15 Jan, 2016 1 commit
-
-
Damien Martin-Guillerez authored
This change make protobuf skylark extension works when using remote repository. Note that this make the Skylark extension unusable prior to Bazel 0.1.4 because the workspace_root is not available on prior version. Tested with Bazel 0.1.4rc2. Fixes https://github.com/bazelbuild/bazel/issues/784.
-