Some users might be depended on these, so until everything is flipped to
explicit imports, need to still provide the class declaration so the proto isn't
a breaking change.
This allows some to use an alternative registry if they have a different
implementation.
This is really just wiring though the change to use the GPBExtensionRegistry
protocol vs the concrete GPBExtensionRegistry through the other apis.
- Remove some types not needed.
- Remove some files not needed.
- Move some tests files into different prefixes to logically segment things.
- Add objc_class_prefix to the files.
- Use an expected prefix file during generation to exercise that code and
validate things.
- Require prefixes for the test file.
- Only output test failures (less to page through)
- Pass the build flags along when checking on the WKTs, otherwise the bazel
flags changed and the compiles have to re-done.
* Fixing typos
* Revert new files that were deleted by sync script
* Fix CMake breakages
* bump upb version
* Sync from Piper @468772608
PROTOBUF_SYNC_PIPER
* Adding abseil to include path for python C++ extension
* Adding abseil linkage for python C++ extension
* Fixing linkage order
* Bazelfying conformance tests
Adding infrastructure to "Bazelify" languages other than Java and C++
* Delete benchmarks for languages supported by other repositories
* Bazelfying benchmark tests
* Bazelfying python
Use upb's system python rule instead of branching tensorflow
* Bazelfying Ruby
* Bazelfying C#
* Bazelfying Objective-c
* Bazelfying Kokoro mac builds
* Bazelfying Kokoro linux builds
* Deleting all deprecated files from autotools cleanup
This boils down to Makefile.am and tests.sh and all of their remaining references
* Cleanup after PR reorganizing
- Enable 32 bit tests
- Move conformance tests back
- Use select statements to select alternate runtimes
- Add internal prefixes to proto library macros
* Updating READMEs to use bazel instead of autotools.
* Bazelfying Kokoro release builds
* First round of review fixes
* Second round of review fixes
* Third round of review fixes
* Filtering out conformance tests from Bazel on Windows (b/241484899)
* Add version metadata that was previously scraped from configure.ac
* fixing typo from previous fix
* Adding ruby version tests
* Bumping pinned upb version, and adding tests to python CI
* Migrating macos php builds from 7.0/7.3 to 7.4/8.0
* Removing local comments
* Fix kokoro issues
* Further cleanup
* Fix permissions in Ruby release test
This is a generation option that provides serves the same purpose as the
existing GPB_OBJC_USE_PACKAGE_AS_PREFIX_PREFIX environment variable; just
providing a different way to set/enable it.
This avoids conflicting names in a couple of cases.
1. Within google, we want to sync files but not name them BUILD (since the structure doesn't match).
2. On case-insensitive filesystems, `build` may be used for a build directory. Naming `BUILD.bazel` avoids potentioal conflicts.
This change adds `rules_pkg`-based targets that will produce source distribution archives, similar to `make dist`.
These rules produce nearly the same outputs as `make dist`. However, there are some differences and caveats:
1. The outputs do not contain vendored googletest sources.
2. You have to run `autogen.sh` before `blaze build pkg:all`. This produces several autotools-related files directly into the source tree.
3. The output .zip files do not have a directory prefix like `protobuf-3.20.1-rc-1` (this will be addressed after [Substitute package variables in `pkg_zip#package_dir`. bazelbuild/rules_pkg#577](https://github.com/bazelbuild/rules_pkg/pull/577); the tar files do have this prefix, though.)
4. One file is missing from the archives, which is produced during the `make` build: benchmarks/gogo/cpp_no_group/cpp_benchmark.cc
5. In several places, I have explicitly excluded some files that are not in the autotools distribution outputs. I think most of those files should probably be included, but for now, I'm aiming for parity with `make dist`. These are marked with comments, so it should be easy to clean them up later.
Swift importing ObjC drops methods/properties if the type is only a forward
declaration since the type is incomplete. Historically the generator has always
use forward declarations to reduce how much will have rebuild when a proto file
does change; but that puts it at odds with Swift. If ObjC Protos end up spanning
Swift modules, the Swift import behavior could become a problem; so this option
provides a control for the behavior. The current behavior is to continue forward
declarations, but eventually the default will be changed.
Generate the WKTs using imports instead of forward decls.
Overdue followup to https://github.com/protocolbuffers/protobuf/pull/7173
Since all the files are at the same level as the runtime headers, there is no
need for things to be framework based imports, they should all just work like
the other headers do.
- Directly generate the bundled header imports into the preamble section when
generating for a bundled proto.
- Update the preamble generation to skip the CPP wrapper when generating for a
bundled proto file.
- Regenerate the WKTs.
- Update GPBProtocolBuffer.h/GPBWellKnownTypes.h to also skip the CPP wrapping.
GPB_USE_PROTOBUF_FRAMEWORK_IMPORTS in the podspec and non bundled files still
has to exist because that comes into play for those files to find the runtime
headers.
* Fix comment syntax in any.proto
Remove extra spaces which cause incorrect indentation in godoc.
Remove the "====" style title which is not rendered by godoc.
* Run ./generate_descriptor_proto.sh
This reverts commit ca3674b7d5.
While there are savings, it ends up being to easy/common to run into issues with
AppStore validation since the selector usage now appears to be a possible match
for private apis vs. for selectors/properties in the generated code.
This likely should have been the default from the start, as without it is way to
common to get symbol collisions between different proto files. It would be nice
to support a "migration" mode where both names are created to aid it moving code
to this model, but with ObjC `@class` decls being very common to avoid header
imports to control rebuilds/etc., it doesn't work as an `@class` usage will
error if one also uses `@compatibility_alias`. Falling back to `#define` the two
together also doesn't work as the header with the `@class` will cause methods to
get defined with one interface, but when methods taking those types are define
will likely #import the generate header and thus get the define and end up with
a different signature. So for now, there is no migration support and code has to
be updated in one shot with enable the new prefixing.
- Add a generation option to enable this change in generation.
- Add a second generation option to provide a list of proto package that are
exceptions from using the proto package. This allows easier
migration/updating of code one package at a time.
Adds an option to protoc `--objc_opt=elide_message_metadata` to remove all the property
metadata from message classes. This significantly reduces the codegen size of the clases.
The downside is that iterating through properties using objective c runtime calls will no
longer function. This is mitigated by the fact that most (all?) of the information that
folks are interested in can be extracted via the message descriptor.
We do this by defining our own classes using the `GPB_MESSAGE_SUBCLASS_IMPL` macro.
Don't check field counts, instead only test based on the fields that exists (and
likely will never exist). This allows the protos to evolve with almost zero
chance of the tests breaking for those other changes.
Thomas Van Lenten
Mike Kruskal
Sandy Zhang
Vy Nguyen
Jorg Brown
David L. Jones
Joshua Haberman
Tamarous
noahdietz
Adam Cozzette
Dimitris Koutsogiorgas
Chris Bainbridge
Matt Kulukundis
Dave MacLachlan