1. 08 Jan, 2020 1 commit
  2. 06 Aug, 2019 1 commit
  3. 29 Jul, 2019 1 commit
  4. 12 Jun, 2019 2 commits
  5. 06 Jun, 2019 1 commit
  6. 28 May, 2019 1 commit
  7. 15 Dec, 2018 1 commit
  8. 16 Nov, 2018 1 commit
  9. 03 Nov, 2018 1 commit
  10. 15 Aug, 2018 1 commit
  11. 21 May, 2018 1 commit
  12. 07 May, 2018 6 commits
  13. 11 Mar, 2018 1 commit
  14. 09 Mar, 2018 1 commit
  15. 12 Jan, 2018 1 commit
  16. 04 Dec, 2017 1 commit
  17. 07 Aug, 2017 2 commits
  18. 03 Apr, 2017 1 commit
  19. 08 Feb, 2017 1 commit
  20. 25 Jan, 2017 1 commit
  21. 16 Dec, 2016 1 commit
  22. 22 Nov, 2016 1 commit
  23. 18 Nov, 2016 1 commit
  24. 12 Oct, 2016 1 commit
    • Florian Weikert's avatar
      Declare all inputs of protoc action · c2b3e70e
      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.
      c2b3e70e
  25. 09 Sep, 2016 1 commit
  26. 15 Aug, 2016 1 commit
  27. 01 Jun, 2016 1 commit
  28. 26 May, 2016 1 commit
    • David Z. Chen's avatar
      Bazel build: Keep generated sources and Python runtime in the same directory. · 02cd45ca
      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`
      02cd45ca
  29. 10 Mar, 2016 1 commit
  30. 25 Feb, 2016 2 commits
    • David Z. Chen's avatar
      Remove hack for building Python support with Bazel. · 985c9684
      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
      985c9684
    • Manjunath Kudlur's avatar
      Fixed grpc C++ plugin support. · f5c73635
      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}.
      f5c73635
  31. 22 Feb, 2016 1 commit
    • Manjunath Kudlur's avatar
      Added grpc plugin support to cc_proto_library. · f0966a74
      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.
      f0966a74
  32. 15 Jan, 2016 1 commit