Adds Automatic-Module-Name after it was lost during the maven-bazel migration (and subsequent re-addition of osgi bundle support).
Updates OsgiWrapper to support adding the Automatic-Module-Name header to the list of properties supported by the `osgi_java_library` rule.
Fixes#12639Closes#14562
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14562 from Sineaggi:add-automatic-module-name a27b3e6695
PiperOrigin-RevId: 579748655
Using none ASCII chars for protoc on Windows are not handled well.
This adresses argument file at a location where either directory, or filename contains Unicode chars.
Specifically because MsBuild tool saves argument file in with the UserName appended to the .rsp file.
https://github.com/dotnet/msbuild/pull/9232
But in general we should really handle if none ascii chars are in the path.
Closes#14197
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14197 from hknielsen:support-non-ascii-commandline-args 673d575665
PiperOrigin-RevId: 568722987
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
This change moves the upb Fastbuild, Optimized, and FastTable test runs over to
the protobuf repo CI in preparation for moving the upb codebase itself. There
are a bunch more test runs to move, but this initial change handles the easy
ones first.
I also updated our pinned upb version to the current head to pick up some
recent fixes.
PiperOrigin-RevId: 557486174
For now, this only covers linux on the two architectures we have testing support for. However, it serves as a good sanity check and can be expanded in the future.
PiperOrigin-RevId: 514449399
For now, this only covers linux on the two architectures we have testing support for. However, it serves as a good sanity check and can be expanded in the future.
PiperOrigin-RevId: 514449399
This deletes our old branches of internal Abseil code in favor of their newly open-sourced library. Notably, this removes the ability to turn CHECK crashes into exceptions.
PiperOrigin-RevId: 504460562
This bumps us to gcc 6 (rather than 4.8), which fully supports C++14, and migrates the Python tests to our Bazel-based system. C#, PHP, and Ruby will remain on CMake + alternate build system for now.
PiperOrigin-RevId: 495501807
* Do not force C++14
Rather than forcing protobuf to always compile in exactly C++14, overriding all settings in .bazelrc and environment variables and commandline options, instead guard the codebase against versions that are too low. This allows for compiling in higher C++ standards, such as those that have std::string_view instead of absl::string_view without generating objects that are incompatible.
* Do not guard headers against low C++ versions
The code will break below C++14 anyway
* Attempt a different >=C++14 guard condition
* Steal the >=C++14 guard condition code from absl
* Special case C++14 guard for GCC < 5.0
* Enable warnings as errors by default for test builds
* Fixing C++ warnings
* Adding host flags, and enabling warnings as error for non-C++ too
* Switch to BUILD copts instead of bazelrc to treat Windows as a snowflake
* Disable warnings as errors on Windows, since it doesn't like the c++14 flag
* 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
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.)