Skip to content
This repository has been archived by the owner on May 25, 2024. It is now read-only.

Commit

Permalink
Upgrade protobuf dependency to v3.8.0 to support TensorFlow 2.2.0.
Browse files Browse the repository at this point in the history
PiperOrigin-RevId: 340957321
  • Loading branch information
cmclean authored and copybara-github committed Nov 6, 2020
1 parent 233847d commit 27d8720
Show file tree
Hide file tree
Showing 3 changed files with 9 additions and 25 deletions.
2 changes: 1 addition & 1 deletion .bazelrc
Original file line number Diff line number Diff line change
Expand Up @@ -60,4 +60,4 @@ test --test_output=errors
# toolchain. See https://github.com/bazelbuild/bazel/issues/7899. You can
# temporarily revert to the legacy flag-based way of specifying toolchains by
# setting `--incompatible_use_python_toolchains=false`."
build --python_top=//:nucleus_python_runtime --incompatible_use_python_toolchains=false --incompatible_depset_is_not_iterable=false
build --python_top=//:nucleus_python_runtime --incompatible_use_python_toolchains=false
4 changes: 2 additions & 2 deletions install.sh
Original file line number Diff line number Diff line change
Expand Up @@ -30,8 +30,8 @@
# Global setting for nucleus builds
# ------------------------------------------------------------------------------

NUCLEUS_BAZEL_VERSION="0.29.1"
NUCLEUS_TENSORFLOW_VERSION="2.1.0"
NUCLEUS_BAZEL_VERSION="2.0.0"
NUCLEUS_TENSORFLOW_VERSION="2.2.0"

function note_build_stage {
echo "========== [$(date)] Stage '${1}' starting"
Expand Down
28 changes: 6 additions & 22 deletions third_party/protobuf.BUILD
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ config_setting(
# ZLIB configuration
################################################################################

ZLIB_DEPS = ["@zlib_archive//:zlib"]
ZLIB_DEPS = ["@zlib//:zlib"]

################################################################################
# Protobuf Runtime Library
Expand Down Expand Up @@ -230,10 +230,7 @@ cc_library(
# TODO(keveman): Remove this target once the support gets added to Bazel.
cc_library(
name = "protobuf_headers",
hdrs = glob([
"src/**/*.h",
"src/**/*.inc",
]),
hdrs = glob(["src/**/*.h"]),
includes = ["src/"],
visibility = ["//visibility:public"],
)
Expand Down Expand Up @@ -762,24 +759,11 @@ cc_binary(
deps = [
":protobuf",
":proto_api",
# This is an ugly but necessary hack to get the Nucleus protobuf
# descriptors loaded into the generated DescriptorPool managed by
# _message.so. Without this, Nucleus "fast_cpp_protos" will be
# backed by DynamicMessages and not the true C++ generated classes.
# That in turn will cause fast conversions in
# nucleus/util/proto_clif_converter.h to break.
# Also, this relies on dlopen() (which Python uses to load C++
# extension modules like _message.so) initializing C++ static objects
# before returning. That is true on Linux, Solaris, BSD, and OS/X,
# but not guaranteed by POSIX. See
# https://stackoverflow.com/questions/40115688/are-static-c-objects-in-dynamically-loaded-libraries-initialized-before-dlopen
# "@" is the name of the base repository. We have to use that, and
# not "@nucleus" here and below, because @nucleus//foobar is somehow
# a different location than @//foobar.
# The below Nucleus-specific dependencies cause its protobuf descriptors
# to be loaded into the DescriptorPool managed by _message.so and put
# all Nucleus C++ extensions here to avoid ODR violations. See
# an internal document for more details.
"@//nucleus/protos:all_nucleus_protos_cc",
# This is an even uglier hack to put all of Nucleus's C++ extension
# code into this C++ extension, so that there is only one C++
# extension, and no ODR violations.
"@//:all_extensions",
] + select({
"//conditions:default": [],
Expand Down

0 comments on commit 27d8720

Please sign in to comment.