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
Github PR 247[0] changed the way that wangle chose which headers to install. As part of this, certain directories, for example , were filtered out. Unfortunately this filtering is performed on the absolute path of the source code. If wangle is cloned underneath any directory which matches one of the filtered directories, then all the header files will be filtered out and no headers installed. Fix this by changing the initial list to be relative to the source directory such that the filtering cannot mistakenly match on paths outside the wangle source tree. [0] https://github.com/facebook/wangle/pull/247
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: 545. Primary language: C++. Languages: C++ (66.4%), Python (24.2%), CMake (8.9%), Starlark (0.2%), C (0.2%). License: Apache-2.0. Latest release: v2026.03.02.00 (3d ago). Open PRs: 14, open issues: 34. Last activity: 5h ago. Community health: 75%. Top contributors: wez, ahornby, yfeldblum, simpkins, chadaustin, knekritz, Orvid, ckwalsh, fanzeyi, afrind and others.
Last 12 weeks · 144 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: 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