These are all "toolchain-y" things, like copts, link_opts, and config_settings. These are very different from what is in //toolchain, though, so I chose the somewhat common name build_defs for the package. For now, I am only using this package for purely internal things. (Most public "defs"-type things should come from rules_proto/rules_cc, anyhow.)
This unrolls several lists based on WELL_KNOWN_PROTO maps, and move internal java codegen rules next to the corresponding java_library targets that expose them.
This adds logic to generate files with lists of files in cmake and automake syntax. This will allow Bazel to serve as the single Source of Truth for library sources, with cmake and automake using Bazel-derived definitions.
The definition files are not yet generated or checked in, but that will be a fairly straightforward set of follow-up changes.
When generating, it isn't uncommon to have generate >1 file at a time, and it is
likely that one file will include another. So cache the results as the
calculation is done so the work isn't repeated.
The previous pruning method didn't have any concept of tracking already done
work, this changes the algorithm to avoid the repeated work to make things more
minimal on the way up.
Some extremely deep proto graphs, this takes the generation time from around 15
min to under 45 seconds.
* Rollback pull request #9852, which will break clients who don't IWYU and depend on us for these STL headers
* Rolling forward https://github.com/protocolbuffers/protobuf/pull/9852 after confirming it doesn't break google internals
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.
These filenames stutter, but are still being used by some users. So, these forward to the correct header. They should eventually be deprecated and removed.
Start reducing our reliance on autotools
This commit updates a few of our CI scripts to build protoc using Bazel
instead of autotools. I also updated the setuptools and Rake build
configs to look for protoc under bazel-bin/ so that they will
preferentially use a Bazel-built protoc binary. The goal is to start
chipping away at our use of autotools in preparation for eventually
dropping autotools support.