This prevents the Bazel `CcProtoAspect` from generating and linking
C++ object code for these files. Without this blacklist, symbols for
protobuf types depended on by `libprotobuf` may be defined multiple
times and violate the ODR rule.
Fixes https://github.com/google/protobuf/issues/4311
Fixes: #4256.
Bazel@HEAD supports Java 9.
The current code has one single issue with Java 9 compliance: the usage
of sun.misc package. We add jdk.unsupported module with --add-modules
compiler option for now. Long term, the usage of non public API should
be avoided.
To build with Java 9, build custom bazel version and issue:
$ bazel --host_javabase=/usr/lib64/jvm/java-9-openjdk build \
--javacopt='--release 9' \
--java_toolchain=@bazel_tools//tools/jdk:toolchain_jdk9 \
:protobuf_java
-Wno-writable-strings removes 230 "ISO C++11 does not allow conversion from
string literal to 'char *'" warnings from TensorFlow test / build output.
These happen because pyext/ sources pass string literals to Python C API data
structures, e.g. PyGetSetDef, which for some reason were designed to not have
the const qualifier.
The SDK and os versions were hard coded. Archs were mixed up.
Because of this, Was getting errors with latest SDK:
clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.2.sdk/' [-Wmissing-sysroot]
clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.2.sdk/' [-Wmissing-sysroot]
clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.2.sdk/' [-Wmissing-sysroot]
In file included from external/com_google_protobuf/src/google/protobuf/io/printer.cc:35:
In file included from external/com_google_protobuf/src/google/protobuf/io/printer.h:40:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string:470:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string_view:171:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__string:56:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:638:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cstring:61:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string.h:61:15: fatal error: 'string.h' file not found
^~~~~~~~~~
1 error generated.
Currently none of these are needed when using bazel with https://github.com/bazelbuild/rules_apple.
-target arm64-apple-ios is passed properly to clang. So -arch armv7 etc are not needed.
OS_IOS is not used anywhere.
Sources have: GOOGLE_PROTOBUF_NO_THREADLOCAL defined in src/google/protobuf/stubs/platform_macros.h for iOS. So __thread= is not needed. In fact now that bazel is using C++11 by default, __thread should ideally be moved to thread_local.
-miphoneos-version-min is passed by rules_apple.
The SDK and os versions were hard coded. Archs were mixed up.
Because of this, Was getting errors with latest SDK:
clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.2.sdk/' [-Wmissing-sysroot]
clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.2.sdk/' [-Wmissing-sysroot]
clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.2.sdk/' [-Wmissing-sysroot]
In file included from external/com_google_protobuf/src/google/protobuf/io/printer.cc:35:
In file included from external/com_google_protobuf/src/google/protobuf/io/printer.h:40:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string:470:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string_view:171:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__string:56:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:638:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cstring:61:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string.h:61:15: fatal error: 'string.h' file not found
^~~~~~~~~~
1 error generated.
Currently none of these are needed when using bazel with https://github.com/bazelbuild/rules_apple.
-target arm64-apple-ios is passed properly to clang. So -arch armv7 etc are not needed.
OS_IOS is not used anywhere.
Sources have: GOOGLE_PROTOBUF_NO_THREADLOCAL defined in src/google/protobuf/stubs/platform_macros.h for iOS. So __thread= is not needed. In fact now that bazel is using C++11 by default, __thread should ideally be moved to thread_local.
-miphoneos-version-min is passed by rules_apple.
Adds a proto_library rule for each well known type proto:
$ bazel query "filter(\".*_proto$\", \"...\")"
//:wrappers_proto
//:timestamp_proto
//:struct_proto
//:field_mask_proto
//:empty_proto
//:duration_proto
//:compiler_plugin_proto
//:descriptor_proto
//:api_proto
//:type_proto
//:source_context_proto
//:any_proto
Bazel users can reference these proto_library rules for their own
language specific rules i.e.
java_proto_library(
name = "any_java_proto",
deps = ["@com_google_protobuf//:any_proto"],
)
Also set the workspace name to "com_google_protobuf", as proto_library
rules reference protobuf that way.
Add implementations of open(2), mkdir(2), stat(2),
etc. that support long paths under Windows (paths
longer than MAX_PATH in <windows.h>, which is 260
characters).
The implementations are in a separate namespace
(google::protobuf::internal::win32), so they won't
collide with the standard implementations in
<io.h>, but after importing them with `using` they
can be drop-in replacements.
Fixes https://github.com/bazelbuild/bazel/issues/2634
Fixes https://github.com/google/protobuf/issues/2891
Bazel's built-in cc_proto_library rule uses a proto_lang_toolchain to learn how to invoke proto-compiler.
To use Bazel's cc_proto_library, add the following to your project's WORKSPACE file:
local_repository(
name = "com_google_protobuf_cc",
path = "/path/to/protobuf-distribution/"
)
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`
proto3.
Added a couple unit test proto3 files, for arena_lite and lite. Cloned
the proto3_arena_unittest to test some of the basics of generated code
(and to ensure that the generated proto3 test files are used by some
test).
John Millikin
David Ostrovsky
Adam Cozzette
Justine Tunney
Jisi Liu
Param Reddy
Seth Greenstein
Feng Xiao
Jakob Buchgraber
Laszlo Csomor
Yun Peng
makdharma
cgrushko
Bairen Yi
Byron Yi
Adam Michael
Manjunath Kudlur
Daniel Ylitalo
Richard Shin
Andy Hochhaus
Jisi Liu
Piotr Sikora
David Z. Chen
Chad Whipkey
Andrew Harp