I want to make a game in C and my goal is to isolate the game engine code from the game logic code, so I can potentially reuse some of the logic and have separate git repos:
-- MyPersonalProjects
| -- TheEngine (library)
| | -- src...
| -- TheGame (depends on TheEngine)
| | -- src...
| -- AnotherGame (depends on TheEngine)
| | -- src...
I'm new to C (coming from Unity C#), so the build system is still something I'm trying to figure out.
Using CMake, how would I go about linking the engine to the game? Using a relative path? Copying the .a
file to each engine? Or is there a better way to go about this?
IDE: CLion for Mac
CodePudding user response:
If you just have an engine and a bunch of games, it's good enough to include the engine as a git submodule to each game and then call add_subdirectory
on the engine from inside each. For a sketch:
cmake_minimum_required(VERSION 3.21)
project(Game)
add_subdirectory(Engine)
# ...
target_link_libraries(Game PRIVATE Engine::Engine)
The primary advantage of this method is that it is easy to use and maintain. There are no install rules to write or package managers to learn. The primary disadvantage is that you'll have to wait for the whole engine to build for each game. CCache is a partial mitigation (doesn't work on Windows, can fail for silly reasons).
Another disadvantage is that it doesn't scale. A 1-to-N dependency graph is easy to track. An arbitrary dependency DAG is not. As you scale up and build times increase, the value prop of integrating with a package manager, like vcpkg (or Conan) increases significantly.