A modern engine is not just a collection of C++ files — it is a modular system built from independent components. To support this architecture, we need a build system that is:

• target based
• modular
• cross platform
• predictable
• easy to extend
• easy to debug

CMake is the industry standard for this kind of work, but most tutorials teach outdated patterns. This article presents modern CMake, designed specifically for multi module engines.

Old CMake relied on:

• global variables
• manual include paths
• implicit linking
• directory level magic

Modern CMake uses:

• targets
• explicit dependencies
• PUBLIC / PRIVATE / INTERFACE scopes
• CMakePresets.json
• per module CMakeLists

This shift is essential for engine architecture.

Engines usually have many modules. Our engine has the following modules:

• glew
• image
• math
• platform
• renderer
• resources
• simulation
• utils

Each module must be:

• built independently
• linked explicitly
• tested in isolation
• extended without breaking others

Target based CMake makes this possible.

The GusOnGames engine uses a top level CMakeLists plus module level CMakeLists.

The top level file:

• defines the project
• sets global policies
• configures C++ standard
• loads third party dependencies
• adds engine modules
• adds examples

It does not contain build logic for modules.

This keeps the top level file clean and readable.

Each module has its own CMakeLists:

• engine/glew/CMakeLists.txt
• engine/image/CMakeLists.txt
• engine/math/CMakeLists.txt
• engine/platform/CMakeLists.txt
• engine/render/CMakeLists.txt
• engine/resources/CMakeLists.txt
• engine/simulation/CMakeLists.txt
• engine/utils/CMakeLists.txt

Each module:

• declares a library
• lists its sources
• exposes its public headers
• defines its dependencies

This enforces clean boundaries.

Each module defines its own namespace

• btg_image
• btg_math
• btg_platform
• btg_renderer
• btg_resources
• btg_simulation
• btg_utils

This avoids collisions and keeps naming consistent. GLEW is an external library we compile ourselves, but we do not modify in any way. It is written in C and thus has no namespace support.

This is the heart of modern CMake.

The dependency affects:

• the module itself
• anything that links to it

Example: math headers.

The dependency affects:

• only the module itself

Example: internal helper libraries.

The dependency affects:

• only consumers
• not the module itself

Example: header only libraries.

CMakePresets.json is the modern way to define build configurations.

It allows you to define:

• Debug / Release
• MSVC / Clang / GCC
• Ninja / Visual Studio
• engine specific presets
• example specific presets

This makes the engine easy to build on:

• Windows
• Linux
• macOS

And easy to integrate with IDEs.

Configure presets:

• windows-msvc-debug
• windows-msvc-release
• linux-clang-debug
• linux-clang-release
• ninja-debug
• ninja-release

Build presets:

• build-debug
• build-release

Test presets (future):

• engine-tests

This gives developers a predictable workflow.

The engine uses only one library which is built inside the engine.

• GLEW (OpenGL loader)

This, as well as any other libraries we might add, should be:

• included as submodules
• built as separate targets
• linked explicitly
• never copied manually

This keeps the engine clean and maintainable.

The top level CMakeLists orchestrates the entire engine.

add_subdirectory(engine/glew)
add_subdirectory(engine/image)
add_subdirectory(engine/math)
add_subdirectory(engine/platform)
add_subdirectory(engine/render)
add_subdirectory(engine/resources)
add_subdirectory(engine/simulation)
add_subdirectory(engine/utils)

add_subdirectory(examples/basic_triangle)
add_subdirectory(examples/physics_demo)
add_subdirectory(examples/game_demo)

Examples are separate executables that link to engine modules.

Example:

target_link_libraries(game_demo
    PRIVATE
        engine_platform
        engine_renderer
        engine_simulation
        engine_resources
        engine_math
)

This makes dependencies explicit and predictable.

This article defined the build architecture of the GusOnGames engine:

• target based CMake
• module level CMakeLists
• clean dependency rules
• PUBLIC / PRIVATE / INTERFACE
• CMakePresets for cross platform builds
• third party integration
• example orchestration

This build system is modern, scalable, and perfectly aligned with the engine’s modular architecture.