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.
