Tags · stephenberry/glaze

Centralize Asio backend selection into a glaze::asio target (#2599) (#…

…2604)

* Centralize Asio backend selection into a glaze::asio target (#2599)

The CMake configuration selected Boost.Asio first, while
glaze/ext/glaze_asio.hpp prefers standalone Asio whenever <asio.hpp> is
includable. On a system with both installed, CMake could link Boost while
the header silently compiled against standalone Asio, producing spurious
LSP errors and, in mixed-link situations, build failures.

Add cmake/glaze-asio.cmake as the single source of truth for backend
selection. glaze_setup_asio() creates the glaze_asio interface target and
the glaze::asio alias, wired to exactly one backend (Boost / standalone /
bundled). When Boost is chosen it defines GLZ_USE_BOOST_ASIO on the target,
keeping the header in lockstep with the backend CMake actually links so the
two can never disagree.

Route the in-tree consumers (tests, networking rest_test, and the HTTP
benchmark) through glaze::asio, removing the duplicated selection logic that
each previously rolled by hand.

* Export glaze::asio to find_package consumers and document the macro pair

Ship cmake/glaze-asio.cmake and FindAsio.cmake with the installed package
and include the module from glazeConfig.cmake, so find_package(glaze)
consumers can call glaze_setup_asio() and link glaze::asio to get the same
backend selection and GLZ_USE_BOOST_ASIO bridge as in-tree builds. This
closes the remaining gap from #2599 where downstream consumers on a system
with both Boost and standalone Asio could link Boost while the header
compiled against standalone Asio.

Also add a comment in glaze_asio.hpp distinguishing the input macro
GLZ_USE_BOOST_ASIO from the output macro GLZ_USING_BOOST_ASIO, and document
the glaze::asio target in docs/networking/asio-setup.md.