Shiver doesn't ship precompiled binaries. Games integrate it by building from source – the same way you'd pull in any CMake dependency with FetchContent or a submodule.
If there ever comes a day that Shiver is used by devs who are not contributing to Shiver: their choice of tooling distribution is up to them. They may choose to build an installer for their team to install Shiver development tools on developer machines or they may integrate from source like I do.
The top level splits into four areas:
Every engine library follows the same pattern: a Code/ directory
containing Include/, Source/, and optionally UnitTest/. The
separation between Include/ and Source/ is a public/private
distinction – Include/ is what downstream code sees, Source/ is
what only that library sees.
This isn't novel, but keeping it consistent across all libraries makes
it easy to set up CMake targets mechanically: Include/ goes on the
public interface, Source/ stays private.
When BUILD_TESTS is set in CMake, any library with a UnitTest/
folder automatically gets a test project. The tests live next to the
code they test rather than in a separate top-level directory, which I
prefer – it keeps the feedback loop tight when working on a specific
library.
Games link Shiver libraries the same way they'd link any CMake dependency:
include(FetchContent)
FetchContent_Declare(
Shiver
URL https://git.xo.codes/shiver/shiver/archive/refs/tags/v1.0.0.zip
)
FetchContent_MakeAvailable(Shiver)
target_link_libraries(MyGame
PRIVATE
Shiver-Core
Shiver-App
)
The BuildSystem/cmake/ directory contains the CMake modules that define
each library target. More on the specifics of how those are structured
to come.
xo © 2026 all rights reserved — attribution