Build file?

[Anthony Fisher]

I've been reading through the source code, and messing around with building up a program using the same type of structure (game code as reloadable module, jobification, etc), but I'm stuck on how to actually build that type of thing in CMake (which I gather this app uses).

Is there any portion of a CMake file/files you'd be willing to share, showing how you build the modules and libraries? I haven't gotten CMake to even properly build all the libraries (Tracy seems weird and finicky with C programs?), and am curious how you structure the build, particularly with modules.

I know your particular setup includes asset building/packaging, but was hoping there might be a general code-only CMakeLists.txt that would demonstrate building the program...

[Scott Lembcke]

Oh, hmm. I think that was an accident. I had only meant to scrub the assets and data. I added the CMakeLists.txt and freshened up the mirrored code while I was at it.

To answer your particular question, look for the DRIFT_MODULES variable in CMakeLists.txt. ("Drift" was the game's working name before I settled on Veridian Expanse, and "modules" because I originally thought I might have multiple modules I could load. So that's what's up with the funky name.)

Basically I split the game into a few separate pieces:

• The executable is just main.c, the entry point. It parses a few CLI flags and then jumps into drift-core.
• The drift-core library is all the code that won't or can't be reloaded. (some utils, data structures, the rendering backends, etc)
• The drift-game library is the reloadable code. The game loop, logic, drawing, and my crude editing tools I've built.
• drift-nuklear only exists to work around some warnings, and I didn't know about per-file compile flags at the time. Ignore it...

Originally I just wanted to have the executable and the library with the reloadable code (drift-game), but I couldn't remember the limitations around having a loaded library link against the executable that loaded it. IIRC the rules differ by OS, and managing that would be a pain. So I figured the easy solution was to just split everything else except main() into drift-core. It's just a few duplicate lines in the build script, and hotloading is a debug feature anyway. When building for release, I build static libraries instead and link them all together normally to make a single executable.

A code only build script isn't really possible, and it wouldn't run without the assets anyway. I don't mind sharing the code, but I don't have time to maintain it as a resource. At least not until the game is done anyway. Did you see the blog post I wrote about hotloading? Its structure is much simpler since it's not using a job system. The code is here.

[Anthony Fisher]

I had read through the blog post, and messed around with that structure, but it wasn't getting me all the way built, with additional libraries and defines and such. This is fantastic, thanks!