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
* 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.)