Not sure the history for why there were two objc_library targets, but
given the one has an issue about not working, merge them into a single
target and an alias.
- Use the alias for :objectivec since that naming doesn't seem to follow
the other targets *_library targets here.
- Update :protobuf_objc to be use for the working target and just inline
the sources/headers lists so there is less indirection in the file.
Fixes#5284
* objectivec: Quash -Wself-assign
* objectivec: Set -Wno-vla when building
Objective-C protobuf uses VLAs for performance reasons. Ensure Clang
doesn’t complain about them.
This change reduces the excessive warnings when compiling C++ protobufs like "external/protobuf_archive/python/google/protobuf/pyext/message.cc:2629:1: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]"
`python/google/__init__.py` declares the top-level 'google' namespace so that
`google.protobuf` can be imported alongside other Google Python modules like
`google.auth`.
This works well when installing protobuf via Pip, but the Bazel `//:python_srcs`
rule doesn't include this file in its `srcs`. Bazel implicitly creates an empty
`google/__init__.py`, which does *not* set up a namespace. The result is that
consuming Python protobuf via Bazel breaks all other Google Python libraries.
This fixes#4658.
@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.
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.
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.
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).
This is required to allow Tensorflow to build on Android without hacks. Currently we create a dummy pthread library just to satisfy this dependency for a library that does not exist on Android. See https://github.com/google/protobuf/issues/1373 for more context.
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
