Extend our Java OSGi library to have a version that works for Kotlin. Add a `protobuf_versioned_kt_jvm_library` that creates a bundle with the OSGi manifest and call that instead of `kt_jvm_library` for all our kotlin maven release targets.
Closes#18812
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18812 from deannagarcia:kotlinOSGi 81bab06f61
PiperOrigin-RevId: 686220820
It's somewhat tedious to explicitly set this option on all of our C++ targets,
so I think ideally we should rely primarily on bazelrc files for setting
compiler flags. I tried to completely remove `COPTS`, but unfortunately that
did not work out--we have so many `-Wsign-compare` warnings that I think we
need to keep suppressing them for now or else we will get a lot of complaints.
However, I was able to get to the point where `-Wno-sign-compare` is the only
flag we need in `COPTS` for non-Windows builds. I explicitly set `-DHAVE_ZLIB`
on just the two targets that need it, and removed `-Wno-nonnull` since we are
already compliant with that warning. I moved `-Woverloaded-virtual` to our
bazelrc files so that CI will enforce that we remain compliant with that.
PiperOrigin-RevId: 684863987
Adding java8 tests as a presubmit test to ensure no regression on java8 compatibility since the option will no longer apply to tests.
PiperOrigin-RevId: 681615348
The change is no-op for Bazel < 8, it always falls back to native providers.
When we cherry-pick --incompatible_autoload_externally to older Bazels, ProtoInfo
can be replaced with Starlark implementation, providing that users set the flag so that there is no second implementation exposed from Bazel.
PiperOrigin-RevId: 674561141
Putting it into BUILD files unintentionally forces it on all our downstream users. Instead, we just want to enable this during testing and let them choose for themselves in their builds.
Note, that this expands the scope of -Werror to our entire repo for CI, so a bunch of fixes and opt-outs had to be applied to get this change passing.
Closed#14714
PiperOrigin-RevId: 666903224
We have received several reports in #17036 that the addition of this flag
actually broke the use of command argument files with non-ASCII characters in
their names. It looks like #14253 ended up fixing the original issue with a
different solution anyway. Hopefully this change fixes the issue with non-ASCII
characters.
PiperOrigin-RevId: 655660885
The idea here is to set the existing config "config_msvc" not only
when "msvc-cl" is specified but also when "clang-cl" is specified.
Keep in mind that clang-cl support in protobuf remains to be only
best-effort and untested for now.
PiperOrigin-RevId: 631195504
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
When using bazel platforms and new rules_android_ndk, crosstool_top is actually still `//external:android/crosstool`. The right way to detect Android is to use `constraint_value`.
Closes#16246
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16246 from sifmelcara:fix-platforms dbf3fd58db
PiperOrigin-RevId: 618198820
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
Protobuf Team Bot
deannagarcia
Adam Cozzette
Deanna Garcia
Mike Kruskal
Yohei Yukawa
Ming-Chuan
Ming-Chuan
aiuto
Harald Kjær Nielsen
Gabriel Féron
Clayton Walker
Benjamin Peterson
Son Luong Ngoc
Jakob Buchgraber
zhangskz
Kent Ross
Mike Kruskal