In CMake >= 3.0 it is more idiomatic to set per-target compiler options than global compiler settings. I have kept these options and defines as `PRIVATE` so they won't be exported with the target.
Closes#12916
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12916 from coryan:cleanup-cmake-avoid-global-compile-settings 3d586dc0e8
PiperOrigin-RevId: 536517165
Policy CMP0141 broke our hack to remove /Zi, and there doesn't seem to be a way to strip debug symbols with this policy enabled. We can disable the policy when it exists to get ccache working again and speed up our tests.
PiperOrigin-RevId: 534958215
CMake has fairly strict backwards compatibility behavior. Saying `cmake_minimum_required(VERSION 3.10)` has two effects:
- It requires CMake to be version 3.10 or higher
- It configures CMake to behave exactly as it did in version 3.10
The code used to override some policies to get newer behavior if it was available. The alternative syntax in this PR says "require at least 3.10, and use the behavior (when available) up to 3.26". We can omit policy overrides by doing so. It does not seem like any other policies are important, so we can use the simpler syntax.
Closes#12712
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12712 from coryan:cleanup-cmake-automatically-use-newer-policies 36db0fa17e
PiperOrigin-RevId: 530376446
Allows the use of an external `jsoncpp` library to be used. Replicates the model used by `abseil-cpp` as a "package" or "module" to the `protobuf_JSONCPP_PROVIDER` option.
Resolves: #11827Closes#12577
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12577 from omenos:omenos/cmake-jsoncpp 073edd69b4
PiperOrigin-RevId: 528492610
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 change also removes policy settings that are now already set to
`NEW` by default. There are still two remaining policies that were
introduced in CMake > 3.10, so I left those, and documented the CMake
version they were introduced in so we know when we can later remove them
(when our min version advances beyond that).
The min CMake version supported by Protobuf is documented here:
https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md
PiperOrigin-RevId: 511897379
These will still use MSVC as the compiler, but will no longer generate Visual Studio projects for the builds. Visual Studio is particularly bad at parallelizing builds, and is hostile to ccache.
This change also tweaks the ccache setup to prevent unbounded the growth observed in our github caches. Windows builds have had debug symbols stripped to reduce ccache size by a factor of 2x, and ccache maximum have been tweaked so that we persist fewer older builds.
Before this change, each CMake build took 12 minutes on every run (plus some constant overhead from staleness/gcloud), even with caching or on large multi-core runners. No amount of caching or parallelization made any noticeable difference above noise. With this change, we see the following improvements:
- 12 minutes to build from scratch on normal runners (unchanged)
- 4 minutes on 32-core runners from scratch
- 1 minute with optimal caches available on normal runners.
- 30 seconds on 32-core runners with optimal caches
PiperOrigin-RevId: 508799909
These will still use MSVC as the compiler, but will no longer generate Visual Studio projects for the builds. Visual Studio is particularly bad at parallelizing builds, and is hostile to ccache.
This change also tweaks the ccache setup to prevent unbounded the growth observed in our github caches. Windows builds have had debug symbols stripped to reduce ccache size by a factor of 2x, and ccache maximum have been tweaked so that we persist fewer older builds.
Before this change, each CMake build took 12 minutes on every run (plus some constant overhead from staleness/gcloud), even with caching or on large multi-core runners. No amount of caching or parallelization made any noticeable difference above noise. With this change, we see the following improvements:
- 12 minutes to build from scratch on normal runners (unchanged)
- 4 minutes on 32-core runners from scratch
- 1 minute with optimal caches available on normal runners.
- 30 seconds on 32-core runners with optimal caches
PiperOrigin-RevId: 508799909
This uses ccache + github caching to substantially decrease the time it takes to run CMake builds. Due to Bazel caching, these are some of our slowest tests, causing one of the biggest presubmit bottlenecks
PiperOrigin-RevId: 507667813
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 leaves the decision of which C++ version to use up to our users. We still have a static_assert in port_def.inc that will prevent pre-C++14 usage.
PiperOrigin-RevId: 501351066
--
cc1f708d75 by Joey Parrish <joeyparrish@google.com>:
Fix misdetection of libatomic with strict compiler flags
With strict flags and -Werror, the detection for libatomic breaks, causing it to be included in places where it is not needed. And on macOS, this leads to a link error when libatomic cannot be found.
Closes#10899
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/10900 from joeyparrish:fix-libatomic cc1f708d75
PiperOrigin-RevId: 487859041
This cl hit an issue during the shared library cmake build from ODR violations, leading to mismatched absl hash seeds. The problem was pre-existing but didn't manifest until now, and can be traced to the fact that in shared library builds we linked Abseil statically. All of the cmake changes here remove the underlying ODR violation.
PiperOrigin-RevId: 485787671
This change enables projects that consume protobuf via
`FetchContent_MakeAvailable()` to set the C++ version to be used. This is
necessary, as linking code compiled for different C++ standards is asking for
trouble (and will simply not work in some cases).
Check that any version that might be set in `CMAKE_CXX_STANDARD` is new
enough (C++14 or later). On Cygwin, check if any `-std=gnu++XX` has
already been set. In all cases, default to C++14.
* Proof of concept for Abseil dependency
* Adding most common Abseil libraries
* Fixing shared library breakages
* Switching to quotes over angled brackets
* Disable install target by default
* Fixing abseil to LTS commit
* Upgrade to latest Abseil LTS
* Turning install back on by default, removing unnecessary export statements
* Add note to future self
* Fixing unsafe globals
* Upgrade third_party/googletest submodule to current main branch
We can finally do this upgrade now that we have dropped our autotools
build. Googletest recommends living at head, so let's go straight to the
most recent commit on main. For some reason the googletest archive is
not present in the Bazel build mirror, so I removed that entry and just
left the GitHub download link in our WORKSPACE file.
Googletest now requires C++14, so I updated all the C++11 flags I could
find to C++14 instead. I added a .bazelrc file to add -std=c++14 for all
our Bazel builds.
* Delete the empty //src/google/protobuf:protobuf_test target
* Avoid building C++ unit tests in aarch64 jobs for Python and Ruby
* Upgrade third_party/googletest submodule to current main branch
We can finally do this upgrade now that we have dropped our autotools
build. Googletest recommends living at head, so let's go straight to the
most recent commit on main. For some reason the googletest archive is
not present in the Bazel build mirror, so I removed that entry and just
left the GitHub download link in our WORKSPACE file.
Googletest now requires C++14, so I updated all the C++11 flags I could
find to C++14 instead. I added a .bazelrc file to add -std=c++14 for all
our Bazel builds.
* Delete the empty //src/google/protobuf:protobuf_test target
* Avoid building C++ unit tests in aarch64 jobs for Python and Ruby
* 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
* Adding non-docker builds for protoc in our supported build systems
* Tweaking bazel builds
* Fixing compatibility with older CMake used by kokoro
* Fixing configs to point to proper scripts
* Propagate errors up properly
* Reinstall Bazel, point NMake to compiler, fix broken static_assert in test
* Adding common setup, enabling long paths
* Explicitly pick 64-bit compiler
* Removing arch from nmake build
* Try to upgrade cmake for installation
* Enabling 8.3 filename support (https://bazel.build/docs/windows)
* Fixing choco calls
* Making installation use Release
* Switching to batch for common config
* Fixing some install test issues unique to Windows
* Attempt another way to get shorter Bazel paths
* More windows bazel tweaks
* Fixing shared library failure from non-exported function used in tests
* Use commandline flags instead of bazelrc
* Fix line break mismatch
* Add .exe extension for test plugin on windows
* Add temporary logging
* Switch to rootpath over hardcoded system-dependent plugin path
* Enabling symlinks/runfiles to fix broken test on windows
ericsalo
Protobuf Team Bot
Protobuf Team Bot
Carlos O'Ryan
Mike Kruskal
deannagarcia
Mike Rochefort
zhangskz
Greg Miller
Joey Parrish
Christian Blichmann
Mike Kruskal
Adam Cozzette
Alexander Neumann