`GPBUnknownFields` will be the eventually replacement for `GPBUnknownFieldSet`. This
introduces the type and the changes to `GPBUnknownField`.
The new api will preserve the wire ordering of unknown fields. This is now checked
in conformance tests.
While this adds the type changes and tests them, it does not yet wire the changes
in to the rest of the Runtime, so the conformance tests still done pass.
`GPBUnknownFieldSet` also hasn't been deprecated yet, that will come in later with
the wiring in to the runtime.
PiperOrigin-RevId: 648361455
This change moves almost everything in the `upb/` directory up one level, so
that for example `upb/upb/generated_code_support.h` becomes just
`upb/generated_code_support.h`. The only exceptions I made to this were that I
left `upb/cmake` and `upb/BUILD` where they are, mostly because that avoids
conflict with other files and the current locations seem reasonable for now.
The `python/` directory is a little bit of a challenge because we had to merge
the existing directory there with `upb/python/`. I made `upb/python/BUILD` into
the BUILD file for the merged directory, and it effectively loads the contents
of the other BUILD file via `python/build_targets.bzl`, but I plan to clean
this up soon.
PiperOrigin-RevId: 568651768
A couple weeks ago we moved upb into the protobuf Git repo, and this change
continues the merger of the two repos by making them into a single Bazel repo.
This was mostly a matter of deleting upb's WORKSPACE file and fixing up a bunch
of references to reflect the new structure.
Most of the changes are pretty mechanical, but one thing that needed more
invasive changes was the Python script for generating CMakeLists.txt,
make_cmakelists.py. The WORKSPACE file it relied on no longer exists with this
change, so I updated it to hardcode the information it needed from that file.
PiperOrigin-RevId: 564810016
This is done in basically the same way the C++ does this.
It was tested locally be putting `#error` directives in the pre-generated
sources and running the bazel build (it worked).
PiperOrigin-RevId: 509261352
objc_library really will only build for Apple platforms, so tag it as such.
The objc conformance test really will only build/run on macOS, so tag it as
such.
With these two changes, it should be safer for recursive builds that include
this directory no matter what the host platform is.
PiperOrigin-RevId: 508438744
Since the sources can't reference each other, this is what helps keep them in
sync. Move it out to be a stand alone test in bazel instead of having it wired
into the Xcode projects.
PiperOrigin-RevId: 508429454
In order to flip the flag, all downstream projects should be adapted. However, it is hard to fix them all if there are constant regressions. Adding it to the CI will ensure that once the project can build with incompatible_disallow_empty_glob it can keep building like that.
See: bazelbuild/bazel#15327
PiperOrigin-RevId: 507927389
* 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
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.
Removing language-specific targets from the top-level BUILD file
will allow users to keep their workspaces smaller and easier to
maintain by not depending on language rules they don't need.
Similar work was done for Java in #7190.
Thomas Van Lenten
Protobuf Team Bot
aiuto
Adam Cozzette
Benjamin Peterson
Deanna Garcia
Xavier Bonaventura
Mike Kruskal
David L. Jones
Joshua Haberman
Yannic Bonenberger