Joshua Haberman
eab1fa2765
Our bootstrapping setup compiles multiple versions of the generated code for `descriptor.proto` and `plugin.proto`, one for each stage of the bootstrap. For source files (`.c`), we can always select the correct version of the file in the BUILD rules, but for header files we need to make sure the correct stage's file is always selected via `#include`. Previously we used `cc_library(includes=[])` to make it appear as though our bootstrapped headers had the same names as the "real" headers. This allowed a lot of the code to be agnostic to whether a bootstrap header was being used, which simplified things because we did not have to change the code performing the `#include`. Unfortunately, due to build system limitations, this sometimes led to the incorrect header getting included. This should not have been possible, because we had a clean BUILD graph that should have removed all ambiguity about which header should be available. But in non-sandboxed builds, the compiler was able to find headers that were not actually in `deps=[]`, and worse it preferred those headers over the headers that actually were in `deps=[]`. This led to unintended results and errors about layering check violations. This CL fixes the problem by removing all use of `includes=[]`. We now spell a full pathname to all bootstrap headers, so this class of errors is no longer possible. Unfortunately this adds some complexity, as we have to hard-code these full paths in several places. A nice improvement in this CL is that `bootstrap_upb_proto_library()` can now only be used for bootstrapping; it only exposes the `descriptor_bootstrap.h` / `plugin_bootstrap.h` files. Anyone wanting to use the normal `net/proto2/proto/descriptor.upb.h` file should depend on `//net/proto2/proto:descriptor_upb_c_proto` target instead. PiperOrigin-RevId: 664953196 |
4 months ago | |
---|---|---|
.. | ||
google/protobuf | Auto-generate files after cl/658038844 | 4 months ago |
BUILD.bazel | Fixed layering check violations once and for all in upb bootstrapping. | 4 months ago |
CMakeLists.txt | Auto-generate files after cl/597923328 | 11 months ago |
README.md | Move upb-x/ back to upb/ | 1 year ago |
build_defs.bzl | Added new, split upb rules for MiniTables and the C API. | 1 year ago |
make_cmakelists.py | Move utf8_range into the protobuf repo | 1 year ago |
push_auto_update.sh | Move upb-x/ back to upb/ | 1 year ago |
staleness_test.py | Merge the protobuf and upb Bazel repos | 1 year ago |
staleness_test_lib.py | Move upb-x/ back to upb/ | 1 year ago |
README.md
upb CMake build (EXPERIMENTAL)
upb's CMake support is experimental. The core library builds successfully under CMake, and this is verified by the Bazel tests in this directory. However there is no support for building the upb compiler or for generating .upb.c/upb.h files. This means upb's CMake support is incomplete at best, unless your application is intended to be purely reflective.
If you find this CMake setup useful in its current state, please consider filing an issue so we know. If you have suggestions for how it could be more useful (and particularly if you can contribute some code for it) please feel free to file an issue for that too. Do keep in mind that upb does not currently provide any ABI stability, so we want to avoid providing a shared library.
The CMakeLists.txt is generated from the Bazel BUILD files using the Python scripts in this directory. We want to avoid having two separate sources of truth that both need to be updated when a file is added or removed.
This directory also contains some generated files that would be created
on the fly during a Bazel build. These are automaticaly kept in sync by
the Bazel test //cmake:test_generated_files
.