Vix.cpp v2.6.0

Vix.cpp v2.6.0 is one of the largest releases in the V2 series. This release expands Vix.cpp beyond a C++ runtime and CLI workflow into a broader native application platform. It introduces local-first AI workflows, official vix.app support, Vue + Vix full-stack scaffolding, target-aware build execution, improved test automation, an async-powered development session, and the first serious foundation for game development with vix::game. The focus of this release is not only feature growth. It is about making Vix.cpp more coherent as a runtime-oriented C++ development environment.

Release focus

The main focus of Vix.cpp v2.6.0 is developer workflow integration.

Previous releases established the native runtime, HTTP stack, async execution model, CLI commands, module packaging, and build system foundations. Vix.cpp v2.6.0 builds on that foundation by connecting more parts of the developer experience together:

  • local AI execution through vix::ai::Agent
  • simplified application builds through vix.app
  • Vue + Vix full-stack development workflows
  • safer and smarter build execution
  • automatic test preparation
  • async-based development sessions
  • native game runtime and export foundations

This release makes Vix.cpp feel less like a collection of modules and more like a unified C++ application runtime.

Local-first AI support

Vix.cpp v2.6.0 introduces the new vix::ai_agent module for local-first AI workflows. The public API is exposed through:

#include <vix/ai.hpp>

The main user-facing entry point is vix::ai::Agent.

The first supported provider path is Ollama, which allows local models to be executed from native C++ applications without treating AI as an external-only service.

This is an important direction for Vix.cpp because AI support is added as a native runtime capability, not as a detached scripting layer or cloud-only integration. The CLI also gains the new vix agent command group:

vix agent ask
vix agent analyze
vix agent scan

These commands establish the first user-facing workflow for AI-assisted project interaction inside the Vix ecosystem.

Official vix.app support

Vix.cpp v2.6.0 makes vix.app an official application manifest path for simple C++ applications. The goal of vix.app is to let developers build and run C++ applications without writing a visible CMakeLists.txt for simple executable projects. A generated application can now use:

vix new my_app --app
vix build
vix run
vix dev
vix tests

Internally, Vix still relies on a real CMake/Ninja workflow. The difference is that simple application projects can now be described through a smaller application manifest, while Vix generates the internal CMake project under .vix/generated/app/. This keeps the build system explicit and compatible with native C++ tooling, while reducing the amount of build-system ceremony required for small projects.

Vue + Vix full-stack workflow

Vix.cpp v2.6.0 adds Vue application scaffolding through:

vix new my_app --template vue

Generated Vue + Vix projects include a Vue frontend and a Vix C++ backend. The frontend template includes the standard Vite structure with files such as package.json, index.html, vite.config.js, src/main.js, and src/App.vue.

The development workflow is integrated into vix dev. This means Vix can start the Vue/Vite frontend alongside the C++ backend during development. Vue projects proxy /api requests to the Vix backend, which gives developers a clean full-stack development loop without manually wiring every process. This is not a replacement for frontend tooling. Instead, Vix coordinates the native backend and the frontend dev server as one development workflow.

Build system improvements

Vix.cpp v2.6.0 significantly improves the build workflow. The default build target is now the generic CMake all target instead of guessing a target from the current folder name. This makes default builds safer and closer to standard CMake behavior. The release also adds target-aware vix build execution with safe fallback to CMake/Ninja. When Vix can safely execute a target through its build graph, it can do so. When a target is unsupported, ambiguous, or unsafe, it delegates back to Ninja. This is the right tradeoff for a C++ runtime tool: optimize when the model is safe, but never pretend to understand more than it does. Vix.cpp v2.6.0 also adds:

vix build --warnings
vix build --warning-check
vix build --explain

vix build --warnings provides paginated compiler warning exploration. vix build --warning-check builds with stronger compiler warning flags automatically. vix build --explain explains why files or targets rebuild. Together, these features move vix build closer to a diagnostic tool, not only a build launcher.

vix run and vix dev improvements

vix run now uses the same project execution path as vix build. This matters because build and run behavior should not diverge. A project should not build one way and run through a separate execution path with different assumptions. Vix.cpp v2.6.0 also improves how vix run handles process exits. Normal non-zero exits are no longer treated as runtime crashes. vix dev receives deeper changes.

The dev session now runs on the Vix async runtime. Rebuilds, polling, debounce timers, child-process monitoring, and Ctrl+C shutdown are coordinated through the async execution model. This makes the development loop more aligned with the rest of the Vix runtime architecture. Applications that exit cleanly now stop the dev session instead of being restarted in a loop. Library projects stay in watch/build-only mode, while runnable application projects execute normally. The result is a quieter and more predictable development workflow.

Test workflow improvements

Vix.cpp v2.6.0 improves vix tests. Projects with a tests/ directory can now prepare and run tests automatically when possible, even if the test configuration has not been explicitly completed yet. The command also gains cleaner CTest-based listing and per-test status display. This reduces friction for projects that are still evolving, while keeping compatibility with standard CMake/CTest workflows.

The new vix::reply module

The REPL engine has been moved out of the CLI module into the new standalone vix::reply module. This is an internal architectural improvement, but it matters because the REPL engine is now separated from CLI command implementation details. vix repl now uses this standalone module. This makes the REPL foundation easier to evolve and reuse without coupling it too tightly to the CLI layer.

Lightweight developer IO helpers

Vix.cpp v2.6.0 moves lightweight developer helper APIs into the new vix::io ownership model. This includes headers and APIs such as:

#include <vix/print.hpp>
#include <vix/format.hpp>
#include <vix/inspect.hpp>
#include <vix/input.hpp>
#include <vix/console.hpp>

This change clarifies module boundaries. The core module should not own every developer-facing helper. By moving these APIs into vix::io, Vix keeps vix::core focused while still preserving a simple developer experience through the installed SDK and umbrella headers.

Game runtime foundation

Vix.cpp v2.6.0 introduces the new vix::game module. This is the first major foundation for game development inside Vix.cpp. The module includes support for game loops, scenes, events, entities, assets, background jobs, runtime contexts, editor contexts, and package metadata. The release adds game-aware project generation:

vix new my_game --game
vix new my_game --template game

Generated game projects include:

assets/
game.package.json
src/main.cpp
vix.app
vix.json

Game projects generated by Vix can now use:

vix build
vix run
vix dev
vix game export

This is a significant step because Vix.cpp is no longer limited to backend, CLI, networking, and runtime use cases. It now has the beginning of a native game application workflow.

SDL and OpenGL game backend

The vix::game module now includes a backend foundation with:

  • GameRuntime
  • GameContext
  • NullWindow
  • NullRenderer
  • SDL window backend
  • SDL renderer backend
  • SDL input mapping
  • texture upload
  • sprite rendering
  • runtime diagnostics
  • architecture tests

Vix.cpp v2.6.0 also adds an SDL OpenGL renderer backend. This includes OpenGL context creation through SDL, shader compilation, VAO/VBO/EBO setup, texture upload, sprite rendering, and glDrawElements rendering. The release includes tiny_adventure, a complete game example using SDL windowing, SDL OpenGL rendering, input, asset loading, texture upload, sprite drawing, movement, and simple collision logic. This gives the game module a real executable direction instead of only abstract runtime types.

Game export workflow

Vix.cpp v2.6.0 adds the first vix::game export workflow.

The new export system includes:

  • GameExportConfig
  • GameExporter
  • GameExportManifest
  • GameExportAsset
  • GameAssetPipeline

The CLI now supports:

vix game export

This command exports Vix game projects from game.package.json, generates export.json manifests, scans assets, detects asset types, and records exported asset metadata such as path, type, and size. The export workflow is additive. It does not change existing vix build, vix run, vix dev, or vix new --game behavior.

CMake and package export improvements

Vix.cpp v2.6.0 improves umbrella CMake integration and package export behavior. The umbrella CMake module order has been improved so dependencies are configured before the modules that consume them. VixConfig.cmake has also been improved so umbrella consumers can load exported Vix targets without requiring internal modules such as vix_io as separate packages. The release adds package configuration support for optional game backends:

-DVIX_WITH_GAME_SDL=ON
-DVIX_WITH_GAME_SDL_OPENGL=ON

Standalone and umbrella vix::game builds also receive dedicated support for:

-DVIX_GAME_ENABLE_SDL=ON
-DVIX_GAME_ENABLE_SDL_OPENGL=ON

This makes game backend availability explicit and keeps optional dependencies under control.

CI and standalone module stability

Vix.cpp v2.6.0 improves standalone CI workflows across several modules, including:

  • CLI
  • core
  • reply
  • websocket
  • middleware
  • database
  • ORM
  • net
  • P2P
  • P2P HTTP

The release also fixes isolated module dependency layouts so each standalone module receives the sibling modules it needs during CI builds. Modules that depend on core now preload required dependencies such as json, template, and env before configuring core. These changes are important for a modular C++ codebase because umbrella builds can hide dependency mistakes. Standalone CI forces each module boundary to be explicit.

Highlights

  • Added the new vix::ai_agent module.

  • Added public AI support through <vix/ai.hpp> and vix::ai::Agent.

  • Added Ollama support for local model execution.

  • Added vix agent ask, vix agent analyze, and vix agent scan.

  • Added the standalone vix::reply module for the REPL engine.

  • Added official vix.app support for simple C++ application projects.

  • Added vix.app support in vix build, vix run, vix check, and vix tests.

  • Added Vue + Vix full-stack project scaffolding.

  • Added Vue-aware vix dev support.

  • Added target-aware vix build execution with safe CMake/Ninja fallback.

  • Added fast no-op build detection and ArtifactCache restore support.

  • Added compiler warning summaries and warning exploration commands.

  • Added vix build --warnings, vix build --warning-check, and vix build --explain.

  • Added automatic test preparation in vix tests.

  • Added the new vix::game module.

  • Added game project scaffolding through vix new --game.

  • Added SDL and SDL OpenGL backend foundations for vix::game.

  • Added sprite rendering, texture upload, SDL input mapping, and runtime diagnostics.

  • Added tiny_adventure, a complete Vix game example.

  • Added vix game export.

  • Added exported game manifests and asset metadata.

  • Improved vix dev by moving session orchestration to the Vix async runtime.

  • Improved CMake package export for umbrella consumers and optional game backends.

Compatibility

Vix.cpp v2.6.0 does not introduce breaking changes. Existing CMake projects continue to use CMakeLists.txt directly. vix.app is used only when no CMakeLists.txt exists, and it is currently focused on simple application and executable projects. Library projects continue to use CMakeLists.txt for now. The AI agent module is optional and can be disabled with:

-DVIX_ENABLE_AGENT=OFF

The game module is also optional and can be disabled with:

-DVIX_ENABLE_GAME=OFF

SDL game backend support can be enabled with:

-DVIX_GAME_ENABLE_SDL=ON

SDL OpenGL renderer backend support can be enabled with:

-DVIX_GAME_ENABLE_SDL_OPENGL=ON

The graph executor can be disabled with:

VIX_GRAPH_EXECUTOR=0

Vue support is currently focused on development workflows through vix dev. vix run continues to run the Vix application or backend.

Notes

Vix.cpp v2.6.0 is a major workflow release. It introduces AI, application manifests, Vue development workflows, stronger build diagnostics, async-powered development sessions, and the first serious game runtime foundation. The most important architectural direction is consistency. vix build, vix run, vix dev, vix tests, vix.app, Vue projects, AI commands, and game projects are becoming part of one coherent runtime workflow. That is the long-term direction of Vix.cpp: native C++ development with modern application-level tooling, without hiding the underlying C++ build system when the project needs full control.