Consider splitting the runtime into a regular and a downsized version (for servers/headless apps)

[Duckwhale]

Many programs won't need the full power of WebGPU, GLFW, and other "GUI-like" libraries. Also reduces binary size/build time.

Not sure if I really want to do this, as I didn't like the split that evo-luvi had (and quickly removed it). But now, there are many more libraries and many of them are somewhat specialized. It's nice getting to use them out-of-the-box, but obviously this isn't free.

---

How: Instead of a single "chunky" binary, there'd be two versions:

• Headless: Includes statically-linked core libraries only, plus FFI bindings so the rest can be loaded on demand
• Regular: Everything (huge and kind of bloated), FFI bindings are loaded automatically (no problem with static linkage)

As for libraries, anything required for graphics, windowing, etc. can be moved out of the headless version. Networking/utilities stay.

TBD: Does it make sense to link with OpenSSL dynamically in the headless version? (Probably, yes)

Roadmap:

• [ ] Update ninja build script with presets (requires #128 ?)
• [ ] Add a new EVO_HEADLESS define (or similar)
• [ ] When set, skip the initialization of the FFI bindings
• [ ] Also exclude FFI headers that require any of the optional libraries
• [ ] Update tests to make sure they pass in both versions (headless should dynamically load the libs)
• [ ] Update build workflows to additionalle create and publish a headless binary release
• [ ] Update "building from source" guide
• [ ] Update "self-contained executables" guide to mention DLL/SO need to be installed, headless is available for smaller archives, etc

[Duckwhale]

WIP: Gathering some data before making any final decision...

---

Libraries that are "useless" in server/CLI applications:

• WebGPU
• WebView
• GLFW
• TBD: RML
• TBD: LabSound

Libraries that disproportionally increase CI build times:

• WebGPU: Adds ~5 minutes (Windows)
• OpenSSL: Adds ~7 minutes (Windows)
• TBD: RML
• TBD: LabSound

Libraries that disproportionally increase binary size:

• WebGPU: TBD - Adds ~X (Windows) / ~Y (Linux) / ~Z (OSX)
• OpenSSL: TBD - Adds ~X (Windows) / ~Y (Linux) / ~Z (OSX)
• Rest TBD

TBD: Cold startup time (probably proportionate to binary size); may be impacted slightly by DLL/SO load? (measurable?)

TBD: How much can be gained (with regard to these metrics)? Guess: Removing the "biggest" 3-5 would be worth it.

[Duckwhale]

Should also consider cost/benefit for these primary supported use cases:

• Multimedia, graphics, audio, native or web apps with UI or WebView (heavy)
• Servers or other networking-heavy non-graphical apps (lighter)
• General-purpose tools, CLI apps, scripts (even more lightweight)

Some dependencies are basically free, while some (OpenSSL) are workhorses that come with a heavy cost.

One other, semi-related question is which of the embedded dependencies could be moved to external packages. Realistically, anything that requires C/FFI glue would have to have at least some runtime components that ship by default. The Lua FFI side is pretty lightweight and can be loaded on demand, so there's no reason to omit that. And the static libs can be provided as DLL/SO.