Wangle is a framework providing a set of common client/server abstractions for building services in a consistent, modular, and composable way.
by facebookC++
4 of 6 standards met
Repository: facebook/wangle. Description: Wangle is a framework providing a set of common client/server abstractions for building services in a consistent, modular, and composable way. Stars: 3094, Forks: 544. Primary language: C++. Languages: C++ (67.6%), Python (22.8%), CMake (9.1%), Starlark (0.2%), C (0.2%). License: Apache-2.0. Latest release: v2026.02.23.00 (5d ago). Open PRs: 13, open issues: 34. Last activity: 6h ago. Community health: 75%. Top contributors: wez, ahornby, yfeldblum, simpkins, chadaustin, knekritz, Orvid, ckwalsh, fanzeyi, afrind and others.
Last 12 weeks · 145 commits
Summary Upgrade GitHub Actions to their latest versions to ensure compatibility with Node 24, as Node 20 will reach end-of-life in April 2026. Changes Context Per GitHub's announcement, Node 20 is being deprecated and runners will begin using Node 24 by default starting March 4th, 2026. Why this matters Node 20 EOL: April 2026 Node 24 default: March 4th, 2026 Action**: Update to latest action versions that support Node 24 Security Note Actions that were previously pinned to commit SHAs remain pinned to SHAs (updated to the latest release SHA) to maintain the security benefits of immutable references. Testing These changes only affect CI/CD workflow configurations and should not impact application functionality. The workflows should be tested by running them on a branch before merging.
Summary: X-link: https://github.com/facebook/proxygen/pull/473 X-link: https://github.com/facebook/hhvm/pull/9411 X-link: https://github.com/facebook/fbthrift/pull/587 X-link: https://github.com/facebookincubator/velox/pull/7518 We need a better way to create cxxbridges - something that uses the recommended method of cxxbridge-cmd. This function creates C++ bindings using the [cxx] crate. Original function found here: https://github.com/corrosion-rs/corrosion/blob/master/cmake/Corrosion.cmake#L1390 Differential Revision: D51160627
Summary: Similar to the folly and fizz granular CMake implementations, this adds granular library targets for wangle that work with both static and shared library builds. Key changes: Added WangleFunctions.cmake with wangle_add_library() function Creates OBJECT libraries for compile-once, use-many pattern Creates STATIC libraries (static builds) or INTERFACE libraries linking to monolithic wangle (shared builds) Added generate_cmake.py to auto-generate CMakeLists.txt from BUCK files Added lint_cmake_sync.py for arc lint integration Updated main CMakeLists.txt with FetchContent compatibility and add_subdirectory() calls for all component directories The granular targets install as separate static libraries while maintaining backward compatibility through the monolithic wangle library. Differential Revision: D91009052
HHVM OSS[1] mirrors its Meta first-party library dependencies via shipit and consumes them via so that it can be built as a single CMake project. It also vendors a number of third-party library dependencies such as gflags and glog that are also dependencies of these first-party library dependencies. It currently tries to ensure that the glog include directories and link libraries used when compiling and linking folly point to the vendored glog by setting / which are forwarded to and co. by FindGlog.cmake, but this doesn't work because and co. only consider these hint paths after system default paths have been searched, so the system glog (if any) would end up being preferred. So, explicitly opt into CMP0074[2] to allow HHVM to simply set to override the glog search paths. Alternatively, we could also raise the required CMake version to 3.12 (released in 2018) or newer to get the NEW behavior by default. fbthrift has recently started requiring 3.20.2. [1] https://github.com/facebook/hhvm [2] https://cmake.org/cmake/help/latest/policy/CMP0074.html