4 of 6 standards met
folly_create_monolithic_library() is called unconditionally in the top-level CMakeLists.txt. When folly is consumed via FetchContent / add_subdirectory, the granular component OBJECT libraries are already available as build targets. The monolithic libfolly.a may not be desired in some use cases e.g., downstream projects that link against the granular libs Request: add a CMake option (e.g. FOLLY_BUILD_MONOLITHIC, defaulting to ON) to skip the monolithic library assembly. When off, an INTERFACE target named folly could aggregate the component targets so downstream target_link_libraries(... folly) calls continue to work without change.
Repository: facebook/folly. Description: An open-source C++ library developed and used at Facebook. Stars: 30264, Forks: 5851. Primary language: C++. Languages: C++ (88.8%), Starlark (4.7%), Python (2.3%), CMake (2.2%), C (0.9%). License: Apache-2.0. Latest release: v2026.02.23.00 (5d ago). Open PRs: 100, open issues: 330. Last activity: 20h ago. Community health: 75%. Top contributors: yfeldblum, Orvid, ot, simpkins, snarkmaster, Gownta, dmm-fb, mzlee, tudor, LeeHowes and others.
Last 12 weeks · 572 commits
Greetings from @conan-io, We are trying to update recipe in Conan Center Index: https://github.com/conan-io/conan-center-index/pull/27995#issuecomment-3317452387 While testing, we found that trying to compile folly with C++17 throws several errors, among them: It seems is directly using C++20 features in their source files. So I guess at least C++20 is needed in order to compile the library. But is still safe to be used (as a dependency) from a C++17 context? Menaning that if this library (nowadays) is still think to be used from C++17. In the project README, it clearly says that it is a C++17 library https://github.com/facebook/folly/blob/main/README.md?plain=1#L13