diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/404.html b/vix-site/.vite-ssg-temp/1mc6wisw06/404.html
new file mode 100644
index 000000000..6819fb324
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/404.html
@@ -0,0 +1,11 @@
+
+
+
+
+
+
+
+
+
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/changelog-YD3fSK2P.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/changelog-YD3fSK2P.js
new file mode 100644
index 000000000..5e909998a
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/changelog-YD3fSK2P.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp Changelog
\n
This changelog documents the evolution of Vix.cpp across its public releases.
\n
Each page explains the purpose of the release, the technical changes it introduced, the workflows affected, and the compatibility or validation work behind it. Releases are grouped by development period so related architectural changes remain easy to follow.
\n
V2.8 releases
\n
The v2.8 line introduces vix::realtime, a transport-independent runtime for authoritative stateful applications, then strengthens the everyday C++ development loop, modular application architecture, dependency management, and project mutation safety.
\n
Versions v2.8.0, v2.8.1, and v2.8.2 were published while release, packaging, and distribution issues were still being resolved. They remain part of the project history for traceability, but they should not be used as stable releases. Vix.cpp v2.8.3 is the first stable and supported release of the v2.8 line.
\n
\n
Vix.cpp v2.8.5 stabilizes Vix Realtime and adds module-scoped Git dependencies, canonical module graph validation, dependency ownership and conflict detection, transactional project mutations, interrupted transaction recovery, and stricter Git installation contracts.
\n
\n
Vix.cpp v2.8.4 adds lighter public headers, faster compilation and rebuilds, dependency-aware caching, safer build parallelism, clearer diagnostics, improved cross-compilation controls, and more consistent behavior across vix build, vix run, and vix dev.
\n
\n
Vix.cpp v2.8.3 introduces the stable v2.8 realtime runtime for authoritative stateful applications, with rooms, serialized commands, deterministic events, logical sessions, snapshots, replay, reconnection, presence, persistence stores, and optional WebSocket and PostgreSQL integration.
\n
\n
\n
V2.7 releases
\n
The v2.7 line expands Vix beyond the core build and runtime workflow. It introduces specialized SDK profiles, Vix Note, Vix UI, Vix Requests, application modules, Softadastra Cloud integration, composable SDK installations, improved package management, package and namespace migrations, and the first package-based Note extension system.
\n
\n
Vix.cpp v2.7.8 — adds first-class package moves and namespace migrations across the Vix Registry and CLI, automatic registry pull request creation, dependency-only workspace packages, semantic version ordering, and broader compatibility with managed, system, local, and legacy Vix SDK installations.
\n
\n
Vix.cpp v2.7.7 — introduces package-based extensions for Vix Note, extension discovery and management, registry-aware extension commands, a modernized Vix Reply editor, and more reliable global installation of CLI packages.
\n
\n
Vix.cpp v2.7.6 — adds secure browser-based authentication for Softadastra Cloud, preserves terminal login for scripts and fallback environments, and fixes Cloud API connectivity and HTTPS transport lifetime handling.
\n
\n
Vix.cpp v2.7.5 — fixes composed SDK generation for multi-profile installations and adds safe automatic migration of obsolete lockfile integrity metadata during vix install.
\n
\n
Vix.cpp v2.7.4 — makes installed SDK profiles composable, allowing projects to combine modules from profiles such as web and data without installing the complete all SDK.
\n
\n
Vix.cpp v2.7.3 — adds generated WebSocket modules, API-only backend projects, the first Softadastra Cloud CLI workflow, Git dependencies, global package installation, faster single-file execution, and safer public registry publishing.
\n
\n
Vix.cpp v2.7.2 — adds module-level registry dependencies, keeps dependency resolution in one root vix.lock, links packages to the modules that use them, and introduces timeout and output guards for C++ cells in Vix Note.
\n
\n
Vix.cpp v2.7.1 — introduces Vix App Modules for structuring C++ applications and backends, with manifest-driven activation, generated route registration, module tests, architecture checks, and manifest-aware vix dev rebuilds.
\n
\n
Vix.cpp v2.7.0 — introduces Vix Note, Vix UI, and Vix Requests, together with specialized SDK profiles, CLI-first SDK installation, and the first desktop and mobile application shell workflows.
\n
\n
\n
V2.6 releases
\n
The v2.6 line develops the application workflow around vix.app, backend tooling, runtime reliability, diagnostics, tests, and release validation.
\n
\n
Vix.cpp v2.6.3 — strengthens Core lifecycle and shutdown behavior, adds official benchmark baselines, improves vix run and vix tests, expands sanitizer coverage, and tightens CI and module validation.
\n
\n
Vix.cpp v2.6.2 — improves dependency installation and updates, registry reliability, package listing commands, Windows SDK packaging, crypto helpers, and command diagnostics.
\n
\n
Vix.cpp v2.6.1 — improves runtime and build diagnostics, test failure reporting, SDK release validation, and full-SDK consumer linking through vix::vix.
\n
\n
Vix.cpp v2.6.0 — introduces the AI agent module, the official vix.app workflow, Vue integration, target-aware builds, async-powered vix dev, production backend tooling, and the game runtime foundation.
\n
\n
\n
V2.5 releases
\n
The v2.5 line develops faster execution, generated projects, registry integration, build diagnostics, replay, and the early application manifest architecture.
Vix.cpp v2.5.5 — improves registry dependency linking in vix run, installed module consistency, package exports, and the first experimental vix.app workflow.
\n
\n
Vix.cpp v2.5.3 — introduces execution replay, runtime diagnostics, incremental build graph foundations, improved test and check output, and a dedicated development session engine.
\n
\n
\n
Ecosystem and package architecture
\n
These releases establish the broader module, package, manifest, and direct-execution workflows used by later Vix versions.
Vix.cpp v2.0.0 — begins the V2 architecture by replacing the Boost.Beast-based V1 runtime with a Boost-free native HTTP stack, an async-first execution model, and clearer module boundaries.
\n
\n';
+const changelog = {
+ html
+};
+export {
+ changelog as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/graph-target-executor-default-BAkH8zmA.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/graph-target-executor-default-BAkH8zmA.js
new file mode 100644
index 000000000..d820cc855
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/graph-target-executor-default-BAkH8zmA.js
@@ -0,0 +1,8 @@
+const html = '
Vix Build Graph Target Executor by Default
\n
vix build is becoming more target-aware.
\n
The goal is simple:
\n
build the target that was requested\nskip work that is already known to be clean\nfallback to CMake and Ninja when they are the safer path
Vix still keeps CMake and Ninja compatibility.\nBut Vix now has a stronger build layer on top of them.\nThe graph target executor is now the default path for real build targets.
\n
The previous path
\n
Before this change, vix build mostly behaved like this:
\n
vix build\n -> resolve project\n -> configure CMake if needed\n -> call CMake build\n -> let Ninja execute the target
This path is reliable.\nIt works for existing CMake projects.\nIt works for complex targets.\nIt works for all.
\n
But it also means that even when Vix knows more about the project, it still delegates almost everything to the CMake/Ninja path.\nThat is safe, but not always ideal.
\n
The new target-aware path
\n
For real targets, Vix now uses the graph target executor by default.
\n
Example:
\n
vix build --build-target vix
The path becomes:
\n
vix build\n -> resolve project\n -> configure CMake if needed\n -> import compile_commands.json\n -> import build.ninja\n -> build Vix BuildGraph\n -> resolve requested target\n -> collect target closure\n -> check dirty compile tasks\n -> execute only what is needed
This gives Vix a build view that is more precise than a plain command wrapper.\nVix can now reason about the requested target before deciding what to run.
\n
Why CMake and Ninja are still used
\n
This change does not remove CMake.\nIt does not remove Ninja.\nThe current model is:
\n
CMake -> configuration and compatibility\nNinja -> generated build graph and fallback execution\nVix -> target-aware graph analysis and fast paths
That is important.\nCMake and Ninja are still excellent for compatibility.\nVix uses them as a stable foundation while adding its own build intelligence on top.
\n
Why all stays on the CMake/Ninja path
\n
The all target is different.\nIt is not a single executable.\nIt is not a single library.\nIt is a global target that can include many things:
\n
\n
executables
\n
libraries
\n
tests
\n
examples
\n
generated targets
\n
utility targets
\n
install-related targets
\n
\n
So this still uses the normal CMake/Ninja path:
\n
vix build --build-target all
The rule is:
\n
real target -> graph target executor\nall target -> CMake/Ninja
This keeps the behavior safe.
\n
What the graph executor does
\n
For a target like:
\n
vix build --build-target vix
Vix resolves the graph target and collects its closure.
Then it checks which compile tasks are dirty.\nIf no source, header, command, or output state requires recompilation, the target is clean.\nThe output can look like:
\n
✔ Graph target: vix\n✔ Up to date\n✔ Done
Skipping Ninja when the target is already up to date
\n
One important improvement is that Vix can now skip the final Ninja call when the graph already proves the target is up to date.\nBefore this improvement, even a clean graph could still end with:
\n
ninja -C build-ninja vix
Ninja would then answer:
\n
ninja: no work to do.
That is correct, but still extra work.\nNow the graph executor can detect:
\n
dirty compile tasks: 0\ntarget output exists
Then it can skip Ninja entirely.\nThe internal logic is:
\n
if no dirty compile tasks\nand target outputs exist\nthen return up to date
This makes the no-op path cleaner.
\n
Dirty compile task detection
\n
A key fix was the dirty detection logic.\nFor compile tasks, the output object file should not make the task dirty just because the output node changed.
\n
A compile task should be dirty when:
\n
\n
source changed
\n
header changed
\n
config changed
\n
compile command changed
\n
object output is missing
\n
dependency file is missing
\n
\n
The output object is the result of the task.\nIt should not be treated the same way as an input.\nThe corrected model is:
\n
compile task dirty =\n dirty input\n or missing output
This matters because large projects can have hundreds of compile tasks.\nOn Vix.cpp itself, the vix target selected hundreds of compile tasks.\nAfter the dirty logic was corrected, a clean rebuild correctly reported:
\n
dirty compile tasks: 0
That is the behavior needed for reliable target-aware builds.
\n
Large dirty target fallback
\n
The graph executor can handle target-aware builds.\nBut for very large dirty closures, Ninja is still a better execution engine today.\nSo Vix has a safety fallback.\nIf too many compile tasks are dirty, Vix falls back to Ninja.\nThe rule is not based on the number of selected tasks.\nA large target can select many tasks and still be clean.\nThe rule is based on dirty tasks:
\n
many selected tasks + zero dirty tasks -> fine\nmany selected tasks + many dirty tasks -> fallback to Ninja
This avoids a bad path where Vix tries to directly execute a very large dirty build closure before the graph executor is mature enough for that case.
\n
Cleaner graph logs
\n
During development, graph logs were useful.\nThey showed steps like:
The biggest no-op speedup came from the build-state fast path.\nThe graph executor avoids unnecessary Ninja work.\nBut before reaching the graph executor, Vix may still need to:
\n
\n
load global packages
\n
scan project files
\n
read compile_commands.json
\n
read build.ninja
\n
load dependency files
\n
build the graph
\n
propagate dirty state
\n
\n
For a large repository, that can still cost time.\nSo --fast adds a higher-level shortcut.\nIf the project state matches the last successful build, Vix can return early:
\n
vix build --fast --build-target vix
Expected output:
\n
Checking vix (dev)\n ✔ Up to date in 0.30s
This happens before loading global packages, before rebuilding the graph, and before invoking Ninja.
\n
What build-state checks
\n
The fast path depends on build-state validation.\nIt compares the current state with the last successful build.\nThe state includes information like:
\n
\n
build signature
\n
project fingerprint
\n
build target
\n
project inputs
\n
last artifact metadata
\n
\n
If the state matches, Vix can safely say:
\n
nothing changed
Then it skips the full build pipeline.\nThis is the fastest no-op path.
\n
Benchmark result
\n
On the Vix.cpp repository, the no-op benchmark showed the difference clearly.
for this no-op target build.\nThe important detail is that this benchmark is for a clean no-op state.\nIt does not mean every build is 20x faster.\nIt means Vix can now skip the full pipeline when the project state proves that nothing changed.
\n
Why the benchmark matters
\n
A no-op build is common during development.\nDevelopers often run a build to check whether the project is still valid.\nIf nothing changed, the best build is the one that proves that quickly.\nThe old no-op path still needed to walk through the normal build system.\nThe fast path can now avoid that.\nThis improves the feedback loop.
\n
The current model
\n
The current build model is now:
\n
vix build --build-target all\n -> CMake/Ninja path\n\nvix build --build-target <real-target>\n -> graph target executor\n\nvix build --fast --build-target <real-target>\n -> build-state fast path when valid\n -> fallback to graph/CMake/Ninja when needed
This gives Vix three layers:
\n
fast state check\ntarget-aware graph execution\nCMake/Ninja compatibility fallback
Each layer has a purpose.
\n
Why this is not just a wrapper
\n
A wrapper simply forwards commands.\nVix Build now does more than that.
\n
It can:
\n
\n
resolve a target
\n
import build graph data
\n
track compile tasks
\n
detect dirty work
\n
skip Ninja when safe
\n
fallback when needed
\n
validate build state
\n
return early on no-op builds
\n
\n
This is build-system behavior.\nCMake and Ninja are still part of the pipeline, but Vix now owns more of the decision-making.
\n
Compatibility stays intact
\n
Existing CMake projects continue to work.\nThe CMake path remains the compatibility layer.\nThe graph executor can be disabled:
\n
VIX_GRAPH_EXECUTOR=0 vix build --build-target vix
And all still uses the CMake/Ninja path:
\n
vix build --build-target all
This means the new executor improves the build path without removing the old one.
\n
Why this matters for Vix
\n
Vix is not trying to replace the entire C++ ecosystem in one step.\nThe better path is gradual:
\n
\n
keep compatibility
\n
add graph intelligence
\n
add cache layers
\n
add better diagnostics
\n
make common workflows faster
\n
\n
This change follows that path.\nIt keeps the reliability of CMake/Ninja while allowing Vix to become more than a command wrapper.
\n
What this enables next
\n
Owning the graph opens the door to better build features.\nFuture improvements can include:
\n
\n
explain why a file rebuilt
\n
show which header caused recompilation
\n
restore objects from cache more aggressively
\n
skip more no-op work
\n
improve target diagnostics
\n
make vix.app native builds faster
\n
\n
The graph executor is a foundation.\nIt gives Vix a place to build these features.
\n
Relationship with vix.app
\n
This also helps the long-term vix.app direction.\nToday, vix.app uses generated CMake for compatibility.\nBut the long-term path is:
\n
vix.app\n -> native BuildGraph\n -> ObjectCache\n -> Scheduler\n -> Link
The graph target executor brings Vix closer to that model.\nIt proves that Vix can reason about build targets directly.\nThat is necessary before native vix.app builds can become the fast path.
\n
The principle
\n
The principle is:
\n
use Vix where Vix can be correct\nfallback to CMake/Ninja where they are safer
That is the right balance.\nIt gives users speed without losing compatibility.\nIt gives Vix room to grow without breaking existing C++ projects.
\n
Conclusion
\n
vix build now has a stronger execution model.\nFor real targets, Vix can use its graph executor by default.\nFor clean targets, it can skip unnecessary Ninja work.\nFor no-op builds with --fast, it can return through a build-state fast path.\nAnd for complex or global targets, it still falls back to CMake and Ninja.\nThe result is a build system that stays compatible, but becomes more intelligent:
\n
CMake/Ninja for compatibility\nBuildGraph for target awareness\nBuild state for fast no-op builds
This is an important step toward a faster and clearer C++ build workflow.
\n';
+const graphTargetExecutorDefault = {
+ html
+};
+export {
+ graphTargetExecutorDefault as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/how-vix-build-works-DJr1dwsZ.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/how-vix-build-works-DJr1dwsZ.js
new file mode 100644
index 000000000..fa183339f
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/how-vix-build-works-DJr1dwsZ.js
@@ -0,0 +1,8 @@
+const html = '
How vix build Works
\n
vix build is the command that turns a Vix.cpp project into build outputs.
vix.app\n -> native BuildGraph\n -> ObjectCache\n -> Scheduler\n -> Link
But the current implementation keeps compatibility first.
\n
The main job of vix build
\n
vix build should answer these questions:
\n
What project am I building?\nWhich build preset is active?\nWhere is the build directory?\nWhat is the CMake source directory?\nWhat is the default target name?\nDo I need to configure?\nDo I need to build?\nCan I reuse previous artifacts?\nCan I skip work safely?
A good build command should not blindly rebuild everything.
\n
It should avoid unnecessary work while staying correct.
\n
Project resolution
\n
The first step is project resolution.\nVix needs to find the project root.\nA project root is usually a directory containing one of these files:
\n
CMakeLists.txt\nvix.app
The resolution rule is:
\n
1. If CMakeLists.txt exists, use CMakeLists.txt.\n2. Otherwise, if vix.app exists, use vix.app.
This rule is important because CMake remains the full-control path.
\n
If a CMakeLists.txt exists, Vix does not ignore it.
Why userProjectDir and cmakeSourceDir are separate
\n
For normal CMake projects, the two paths are the same.\nFor vix.app, they are different.\nThat means the build plan must not treat one path as everything.
The plan is the central object used by the build pipeline.\nIt tells the rest of the command what to configure, where to build, and what target to build.
A launcher helps speed up repeated compilation by caching compiler outputs.\nThe build plan can store the resolved launcher.\nThen CMake can receive something like:
\n
CMAKE_CXX_COMPILER_LAUNCHER=ccache
This is one layer of build acceleration.
\n
Fast linker
\n
Vix can also prefer a fast linker when available.
\n
Examples:
\n
mold\nlld
Linking can become a bottleneck in C++ builds.\nUsing a faster linker reduces the cost of incremental builds where only the final link step is needed.\nThis does not remove compilation cost, but it improves the hot path.
\n
CMake compatibility path
\n
The current build pipeline still uses CMake/Ninja as the execution layer.\nThis gives Vix compatibility with:
\n
existing CMake projects\ngenerated CMake from vix.app\nCMake packages\nNinja\ntoolchains\ncompiler launchers\nfast linkers
The compatibility path is important because C++ projects can be very different.\nVix should not break existing workflows.
\n
Build graph layer
\n
Beyond running CMake, Vix can build a deeper model of the build.\nThe build graph layer can import:
This is the beginning of a more intelligent build engine.
\n
compile_commands.json
\n
compile_commands.json contains the exact compiler commands used for translation units.
\n
A typical entry includes:
\n
working directory\nsource file\ncompiler arguments\nobject output
This is useful because Vix should not guess compile flags.\nIt can import the real command emitted by CMake/Ninja.\nThat makes cache decisions more accurate.
\n
build.ninja
\n
build.ninja contains the generated build rules.
\n
Vix can parse it to understand build edges.\nEdges can be classified as:
A compile task turns a source file into an object file.\nA link task turns object files and libraries into an executable.\nAn archive task creates a static library.\nA copy task copies resources or outputs.
\n
Dirty checking
\n
A build system should know whether a task needs to run.\nInputs to dirty checking can include:
This is where a build tool can feel extremely fast.\nThe goal is not to make the compiler magically faster.\nThe goal is to avoid invoking it when there is no work.
\n
Target-aware builds
\n
A target-aware build should only build what is needed for the requested target.\nIf the user runs:
\n
vix build --build-target server
Vix should not do unnecessary work for unrelated targets.\nThis is especially important for larger projects.\nFor vix.app, this is simpler because one manifest usually describes one target.\nFor CMake projects, Vix can rely on CMake/Ninja target information.
\n
Scheduler
\n
A scheduler executes build tasks in dependency order.\nIt can run independent tasks in parallel.
\n
A simple model is:
\n
find ready tasks\nrun ready tasks up to job limit\nmark outputs complete\nunlock dependent tasks\nrepeat
This is the core of parallel builds.\nNinja already does this well.\nVix’s own scheduler becomes important for a future native build path.
\n
Jobs
\n
The -j or --jobs option controls parallelism.
\n
Example:
\n
vix build -j 8
If no job count is provided, Vix can choose a default based on available CPU cores.\nParallelism speeds up compilation when multiple source files can be built independently.
\n
Diagnostics
\n
vix build should not only run commands.\nIt should make failures readable.\nA good diagnostic includes:
\n
error title\nsource location\nmessage\nhint\ncode frame when possible\nraw compiler output when needed
C++ build errors are often noisy.\nVix can improve the developer experience by extracting the useful part.
Vix can parse compiler output and show a cleaner message.\nThe build system should preserve the raw log when needed.
\n
Link errors
\n
Link errors usually come from:
\n
missing library\nmissing symbol\nwrong link order\npackage found but target not linked\nduplicate main()\nundefined reference
For vix.app, a common link mistake is:
\n
packages = [\n fmt:REQUIRED,\n]
without:
\n
links = [\n fmt::fmt,\n]
packages finds packages.
\n
links links targets.
\n
Build logs
\n
Vix can write configure and build logs.\nLogs are important because the terminal output may be filtered or styled.\nA full log helps debug hard build failures.\nCommon logs include:
\n
configure log\nbuild log\nvix log
The UI can stay clean while logs preserve details.
\n
Output style
\n
vix build can present progress in a more readable way than raw build output.\nA build header may include:
The purpose is to show the important build context without flooding the terminal.
\n
Clean builds
\n
A clean build removes previous build outputs and starts again.
\n
Example:
\n
vix build --clean
This is useful when cache or generated files are stale.\nFor vix.app, cleaning should affect build outputs under the user project directory.\nIt should not confuse the generated CMake directory with the project root.
\n
vix.app and build
\n
For vix.app, the current build path is:
\n
load vix.app\nvalidate manifest\ngenerate CMake\ncreate build plan\nconfigure CMake from cmakeSourceDir\nbuild defaultTargetName
Example manifest:
\n
name = hello\ntype = executable\nstandard = c++20\n\nsources = [\n src/main.cpp,\n]
Build:
\n
vix build
Conceptual build command:
\n
cmake --build build-ninja --target hello
Native vix.app build path
\n
The future native path can avoid CMake for simple vix.app projects.\nThe architecture can become:
\n
vix.app\n -> BuildGraph\n -> ObjectCache\n -> Scheduler\n -> Link
This means Vix would create compile and link tasks directly from the manifest.\nCMake would remain available as a fallback and compatibility path.
It can also use Vix-specific caches more directly.\nBut this does not mean C++ compilation becomes free.\nIt means Vix can avoid work more aggressively when it understands the project directly.
\n
Compatibility vs speed
\n
The realistic architecture is:
\n
CMakeLists.txt -> compatibility path\nvix.app -> fast path
CMake projects continue to work.
\n
vix.app projects become the place where Vix can innovate faster.\nThis is a better strategy than trying to replace CMake for every C++ project.
\n
Common build flow
\n
A typical vix build flow looks like this:
\n
1. parse CLI options\n2. resolve project\n3. resolve preset\n4. create build plan\n5. compute configure signature\n6. generate vix.app CMake if needed\n7. configure if needed\n8. build selected target\n9. import build graph if needed\n10. update cache state\n11. print result
Not every step runs every time.\nA no-op build should skip as much as possible.
\n
Common failure points
\n
Common failures include:
\n
project not found\ninvalid vix.app\nsource file not found\nCMake configure failed\npackage not found\ncompiler error\nlinker error\nexecutable not produced\nstale build directory\ninvalid build target
A good build command should make each failure point clear.
\n
Good engineering boundary
\n
vix build should not be only a wrapper around CMake.\nIt should be a build orchestrator.\nToday, it can orchestrate:
vix build is the center of the Vix.cpp build experience.\nIt resolves the project, creates a build plan, configures the build system, builds the target, and prepares for caching and graph-aware execution.\nFor CMake projects, it keeps compatibility.\nFor vix.app projects, it starts with generated CMake and can later become a native fast path.\nThe important architectural lesson is:
\n
project resolution and build planning must be precise
That separation makes the current build correct.\nIt also prepares Vix for the next step:
\n
vix.app -> BuildGraph -> ObjectCache -> Scheduler -> Link
';
+const howVixBuildWorks = {
+ html
+};
+export {
+ howVixBuildWorks as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/how-vix-run-resolves-targets-DYcl8hC6.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/how-vix-run-resolves-targets-DYcl8hC6.js
new file mode 100644
index 000000000..aec952f2e
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/how-vix-run-resolves-targets-DYcl8hC6.js
@@ -0,0 +1,8 @@
+const html = '
How vix run Resolves Targets
\n
vix run is the command that turns a source file or project into something executable, then runs it.
\n
It looks simple from the outside:
\n
vix run
or:
\n
vix run main.cpp
But internally, vix run has to answer several questions:
\n
Is this a single C++ file?\nIs this a project?\nIs the project using CMakeLists.txt?\nIs the project using vix.app?\nWhat target should be built?\nWhere is the executable?\nWhich arguments belong to Vix?\nWhich arguments belong to the program?
Target resolution is the part of vix run that answers these questions.
\n
Two main modes
\n
vix run has two major modes:
\n
script mode\nproject mode
Script mode runs a single C++ file.
\n
Project mode runs a CMake or vix.app project.
\n
Example script mode:
\n
vix run main.cpp
Example project mode:
\n
vix run
from inside a project directory.
\n
Script mode
\n
Script mode is used when the input is a C++ source file.
\n
Example:
\n
vix run main.cpp
In this mode, Vix treats the file as the entry point.
\n
The target identity comes from the source file.
\n
Conceptually:
\n
input file: main.cpp\nscript target: main
Vix can compile the file, link the required libraries, then execute the produced binary.
\n
Project mode
\n
Project mode is used when Vix detects a project root.
\n
A project root contains one of these files:
\n
CMakeLists.txt\nvix.app
Resolution order:
\n
1. CMakeLists.txt\n2. vix.app
If a CMakeLists.txt exists, Vix uses the CMake project.
\n
If no CMakeLists.txt exists but vix.app exists, Vix uses the vix.app project.
\n
Why target resolution matters
\n
Running a project is not only about building.
\n
After building, Vix needs to find the executable.
\n
That requires a target name.
\n
For example:
\n
name = hello\ntype = executable\nstandard = c++20\n\nsources = [\n src/main.cpp,\n]
The executable target is:
\n
hello
So vix run should build and search for:
\n
hello
not necessarily the folder name.
\n
The old simple assumption
\n
For many CMake projects, Vix can guess the target from the project folder.
\n
Example:
\n
hello/\n CMakeLists.txt\n src/\n main.cpp
Folder name:
\n
hello
Target name:
\n
hello
In this case, guessing from the folder works.
\n
But this assumption breaks when the target name differs from the directory name.
\n
vix.app makes target identity explicit
\n
With vix.app, the manifest declares the target name directly:
\n
name = server
The folder could be named:
\n
backend-app/
But the target is:
\n
server
So vix run must use the resolved target name from the manifest.
\n
It should not guess from:
\n
project directory name\ngenerated CMake directory name
Project resolution result
\n
A good project resolver returns enough metadata for vix run.
\n
For a CMake project:
\n
kind = CMake\nuserProjectDir = project/\ncmakeSourceDir = project/\ncmakeListsPath = project/CMakeLists.txt\ntargetName = project folder name or resolved target\ngenerated = false
vix.app\n -> BuildGraph\n -> ObjectCache\n -> Scheduler\n -> Link
vix run should not need a major redesign for that.
\n
If the resolver still provides:
\n
targetName\nbuildDir\noutput path\nproject root
then the execution step stays similar.
\n
Only the build engine changes underneath.
\n
Conclusion
\n
vix run resolves targets by first deciding whether it is running a single file or a project.
\n
For projects, it resolves either:
\n
CMakeLists.txt
or:
\n
vix.app
For vix.app, the manifest name is the target name.
\n
That target name must drive both the build step and the executable lookup.
\n
The key rule is:
\n
do not guess from the generated directory\ndo not guess from the folder when the manifest gives a name
A clean vix run model uses shared project resolution, builds the correct target, finds the executable, and runs it with a clear argument boundary.
\n';
+const howVixRunResolvesTargets = {
+ html
+};
+export {
+ howVixRunResolvesTargets as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/images/vix-ws-chat.png b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/images/vix-ws-chat.png
new file mode 100644
index 000000000..a50da2883
Binary files /dev/null and b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/images/vix-ws-chat.png differ
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/logo/logo.svg b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/logo/logo.svg
new file mode 100644
index 000000000..d210eb9fd
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/logo/logo.svg
@@ -0,0 +1,81 @@
+
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/logo/softadastra.svg b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/logo/softadastra.svg
new file mode 100644
index 000000000..697c9ee06
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/logo/softadastra.svg
@@ -0,0 +1,54 @@
+
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/logo/vix-logo.png b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/logo/vix-logo.png
new file mode 100644
index 000000000..0f1f8f6af
Binary files /dev/null and b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/logo/vix-logo.png differ
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/no-op-target-builds-fast-by-default-NR-_84Go.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/no-op-target-builds-fast-by-default-NR-_84Go.js
new file mode 100644
index 000000000..03d221e86
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/no-op-target-builds-fast-by-default-NR-_84Go.js
@@ -0,0 +1,8 @@
+const html = '
No-op target builds are now fast by default
\n
vix build keeps getting faster, but the most important part is not just speed.\nThe important part is correctness.\nA build tool should never say that a target is up to date unless it can prove it.\nThe latest work on vix build focused on that balance:
\n
fast when safe\ncorrect by default\nfallback when needed
This article explains the latest improvement: normal no-op target builds are now fast too.
\n
The previous result
\n
In the previous benchmark, the --fast path was clearly the fastest path.\nThe result looked like this:
vix build --build-target vix no longer needs to walk through the full pipeline when Vix can already prove that the target is clean.
\n
What changed
\n
Before, --fast had the highest-level shortcut.\nThe normal build path could still pay for work such as:
\n
\n
load project metadata
\n
load global packages
\n
scan project files
\n
load compile_commands.json
\n
load build.ninja
\n
load dependency files
\n
build the graph
\n
propagate dirty state
\n
resolve the target
\n
ask Ninja
\n
\n
That is safe, but it is not always necessary.\nNow the build-state validation can help the normal target build too.\nThe normal path can return early when the state proves:
\n
\n
same build signature
\n
same project fingerprint
\n
same target
\n
same preset
\n
same build type
\n
same compiler identity
\n
same project inputs
\n
last binary still exists
\n
last binary is executable
\n
artifact state is valid
\n
\n
So the normal command can be fast:
\n
vix build --build-target vix
Expected output:
\n
Checking vix (dev)\n ✔ Up to date in 0.3s
Why this matters
\n
This is better than making only --fast fast.
\n
A special flag is useful for power users.\nBut the best developer experience is when the default command is already smart.\nThe user should not need to think:
\n
\n
Should I use --fast here?
\n
\n
For a clean target, Vix can now make the normal command fast when it can prove correctness.\nThat makes the common workflow simpler:
\n
vix build --build-target vix
\n
If nothing changed, Vix returns quickly.
\n
If something changed, Vix rebuilds.
\n
If Vix is unsure, it falls back.
\n
\n
Safety still comes first
\n
The speedup is only valid because Vix does not trust one signal blindly.\nFor example, a build state hit is not enough.\nThe final binary must still exist.\nThe target must match.\nThe project inputs must match.\nThe build signature must match.
\n
If the binary is missing, Vix must not say Up to date. It must rebuild or restore from the artifact cache.
That means even after deleting the build directory, Vix can restore the final target without recompiling.\nThis is a different layer from the object cache.
\n
ObjectCache -> restores .o and .d files\nArtifactCache -> restores the final binary or library
This work is now protected by a build safety test script.\nThe script checks the fragile paths:
\n
\n
build target all
\n
build target real
\n
graph executor enabled
\n
graph executor disabled
\n
--fast state hit
\n
--fast fallback
\n
missing last binary
\n
changed source file
\n
changed header file
\n
changed CMakeLists.txt
\n
changed compiler flags
\n
changed build target
\n
\n
The current result is:
\n
Passed: 12\nFailed: 0
This matters because build optimizations can be dangerous.\nA build system is not allowed to be fast by being wrong.\nEvery shortcut must prove that it is safe.
\n
--explain also improved
\n
The latest work also improved --explain.\nFor source changes, Vix can now explain the rebuild:
For some header changes, when Vix cannot yet map the header precisely to selected compile tasks, it now avoids lying.
\n
Instead of saying:
\n
No rebuild required
it says:
\n
Project input changed\n reason: dependency changed, delegating target to Ninja\n\nRelinking vix\n reason: target may depend on changed input
Then Ninja decides the exact files to rebuild.\nThat is the right behavior.\nIf Vix cannot prove the target is clean, it must not claim that it is clean.
\n
Why Graph Executor still matters
\n
The benchmark now shows similar times for:
\n
\n
--fast
\n
normal target build
\n
Graph Executor disabled
\n
\n
That does not mean the Graph Executor is useless.\nIt means the no-op path is now being solved earlier.\nFor clean builds, the fastest layer wins before the graph executor needs to do much work.\nBut when the project changes, the graph executor still matters because it gives Vix target awareness.
\n
It can:
\n
\n
resolve the requested target
\n
collect the target closure
\n
detect dirty compile tasks
\n
avoid global rebuild assumptions
\n
delegate safely when needed
\n
\n
The long-term direction is still:
\n
CMake/Ninja -> for compatibility\nBuildGraph -> for target intelligence\nObjectCache -> for compile reuse\nArtifactCache -> for target reuse\nBuildState -> for fast no-op validation
That was the previous result.\nThe new conclusion is:
\n
normal no-op target builds are now fast by default
\n
That is a better developer experience.
\n
The principle
\n
The principle remains the same:
\n
fast when safe\ncorrect by default\nfallback when needed
Vix should be fast when it can prove correctness.
\n
\n
If the target is clean, return quickly.
\n
If the final binary is cached, restore it.
\n
If the graph can prove the dirty work, execute only what is needed.
\n
If the graph cannot prove safety, delegate to Ninja.
\n
\n
This is how vix build can become faster without becoming fragile.
\n
Conclusion
\n
The latest vix build work changes the default experience.
\n
Before:
\n
\n
--fast was the fast no-op path
\n
normal target builds were still slower
\n
\n
Now:
\n
\n
normal no-op target builds are fast too\nThat is an important step.\nIt means Vix is not only adding special fast paths.\nIt is making the ordinary command smarter.\nFor developers, that is the real win:
\n
\n
vix build --build-target vix
\n
If nothing changed, it returns in about 300 ms.
\n
If something changed, it rebuilds.
\n
If Vix is unsure, it falls back.\nThat is the kind of build behavior Vix is moving toward.
\n
\n';
+const noOpTargetBuildsFastByDefault = {
+ html
+};
+export {
+ noOpTargetBuildsFastByDefault as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/production-simplicity-checklist-BP1ObsbC.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/production-simplicity-checklist-BP1ObsbC.js
new file mode 100644
index 000000000..91401993e
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/production-simplicity-checklist-BP1ObsbC.js
@@ -0,0 +1,612 @@
+const html = `
Vix Production Simplicity Checklist
+
This checklist comes from analyzing PulseGrid running in production.
+PulseGrid showed an important reality:
+
+
Vix can build and run a real C++ backend, but production still requires too much manual work.
+The goal of this checklist is to make Vix extremely simple for real production apps.
+A developer should be able to build, run, deploy, inspect, debug, and operate a Vix app without manually wiring systemd, Nginx, logs, health checks, ports, services, and production diagnostics.
+
+
+
1. Production diagnosis
+
Goal
+
Vix should understand the production state of an app.
+A command like this should exist:
Vix should not treat normal client disconnects as production errors.
+PulseGrid revealed repeated logs like:
+
[session] write error: Broken pipe
This usually means the client closed the connection before the server finished writing.
+Vix already handles normal disconnects while reading. The same logic must be applied during response writing.
+
Checklist
+
+
Detect normal disconnects in HTTP read path.
+
Detect normal disconnects in HTTP response write path.
+
Log client disconnects at Debug level.
+
Keep unexpected write failures at Error level.
+
Apply similar logic to WebSocket writes.
+
Classify common errors:
+
Broken pipe
+
Connection reset by peer
+
Operation canceled
+
EOF
+
+
+
Add tests for response write disconnects.
+
Add tests for WebSocket disconnects.
+
Avoid noisy logs in production.
+
Improve log messages with context.
+
+
Expected behavior:
+
[session] client disconnected during response write: Broken pipe
instead of:
+
[session] write error: Broken pipe
+
8. WebSocket production support
+
Goal
+
Vix should provide stronger production support for WebSocket apps.
+PulseGrid uses a live WebSocket endpoint for realtime status updates.
+Vix should make this easier to operate and debug.
warning: Vix CLI and Vix libraries come from different installations
+
+CLI:
+ /home/gaspard/vix/build/vix
+
+CMake package:
+ /home/gaspard/vix-clean/build-ninja
+
+This can cause confusing builds.
+
15. Better deploy script generation
+
Status
+
Replaced by vix deploy.
+
The original goal was to generate a safe deployment script while the deployment workflow was incomplete. Since vix deploy now supports pull, build, tests, service restart, service status, health checks, proxy checks, logs on failure, dry-run, verbose mode, and production config from vix.json, a generated deploy script is no longer required for the v2.6 production workflow.
+
Checklist
+
+
Replaced by vix deploy.
+
Use production config from vix.json.
+
Pull latest code optionally.
+
Build app with correct command.
+
Restart service through vix service.
+
Run health checks through vix health.
+
Validate proxy through vix proxy nginx check.
+
Show logs on failure.
+
+
+
16. Production readiness score
+
Goal
+
Vix should provide a simple production readiness score.
+
vix doctor production
Should produce:
+
Production readiness: 82/100
+
+OK service installed
+OK service running
+OK nginx proxy configured
+OK TLS enabled
+OK local health check
+OK public health check
+WARN websocket health not configured
+WARN deploy rollback not configured
Checklist
+
+
Define scoring rules.
+
Show OK/WARN/FAIL.
+
Keep output simple.
+
Make fixes actionable.
+
Do not hide important details.
+
Support JSON output for CI.
+
+
+
17. Immediate fixes from PulseGrid
+
These are the first concrete improvements to implement in Vix.
+
Priority 1
+
+
Fix HTTP response write disconnect logging.
+
Move normal write disconnects to Debug level.
+
Keep unexpected write failures at Error level.
+
Add test for Broken pipe during response write.
+
+
Priority 2
+
+
Add vix doctor production.
+
Detect service, port, proxy, TLS, and health state.
+
Detect CLI/library mismatch.
+
+
Priority 3
+
+
Add vix logs.
+
Read systemd logs.
+
Read Nginx logs.
+
Group common disconnect noise.
+
+
Priority 4
+
+
Add vix service.
+
Generate and manage systemd service.
+
+
Priority 5
+
+
Add vix proxy nginx.
+
Generate and validate Nginx config.
+
+
Priority 6
+
+
Add vix deploy.
+
Build, restart, health check, and show logs on failure.
+
+
+
18. Final product direction
+
PulseGrid proves that Vix should become:
+
+
A C++ runtime that makes production backend apps simple to build, run, deploy, inspect, and operate.
+
+
The developer experience should feel like:
+
vix new pulsegrid --template backend
+vix dev
+vix test
+vix build
+vix service install
+vix proxy nginx init
+vix deploy
+vix doctor production
+vix logs
The long-term goal:
+
No manual systemd.
+No manual Nginx guessing.
+No unclear ports.
+No noisy logs.
+No hidden build mismatch.
+No weak health checks.
+No confusing production state.
Vix should make a production C++ backend feel simple, visible, and reliable.
+`;
+const productionSimplicityChecklist = {
+ html
+};
+export {
+ productionSimplicityChecklist as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/apple-touch-icon.png b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/apple-touch-icon.png
new file mode 100644
index 000000000..ff8129fc0
Binary files /dev/null and b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/apple-touch-icon.png differ
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/favicon-16x16.png b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/favicon-16x16.png
new file mode 100644
index 000000000..91ce8f2c8
Binary files /dev/null and b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/favicon-16x16.png differ
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/favicon-32x32.png b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/favicon-32x32.png
new file mode 100644
index 000000000..5a237f32f
Binary files /dev/null and b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/favicon-32x32.png differ
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/favicon.ico b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/favicon.ico
new file mode 100644
index 000000000..d84e1a2ab
Binary files /dev/null and b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/favicon.ico differ
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/icon-192.png b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/icon-192.png
new file mode 100644
index 000000000..3e9fb8be1
Binary files /dev/null and b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/icon-192.png differ
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/icon-512-maskable.png b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/icon-512-maskable.png
new file mode 100644
index 000000000..0f1f8f6af
Binary files /dev/null and b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/icon-512-maskable.png differ
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/icon-512.png b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/icon-512.png
new file mode 100644
index 000000000..0f1f8f6af
Binary files /dev/null and b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/pwa/icon-512.png differ
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/roadmap-BeH2oDRh.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/roadmap-BeH2oDRh.js
new file mode 100644
index 000000000..1d49b370f
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/roadmap-BeH2oDRh.js
@@ -0,0 +1,8 @@
+const html = '
Roadmap
\n
Technical roadmap for the evolution of Vix.cpp.
\n
These notes document where Vix is going next: production backend tooling, deployment workflows, service management, reverse proxy support, health checks, logs, diagnostics, and operational reliability.
\n
The goal is simple: make serious C++ backend applications easier to build, run, deploy, inspect, and operate.
This is practical.\nIt gives users a simple manifest while keeping compatibility with the C++ build ecosystem.\nThe generated CMake path means Vix can support vix.app without rewriting the entire build engine first.
\n
Why generated CMake is a good first step
\n
Generated CMake gives Vix three things immediately:
For complex projects, this overhead is acceptable.\nFor simple projects, Vix can eventually do better.\nA vix.app manifest already gives Vix the important build information directly:
Vix should not try to understand all arbitrary CMake logic.\nCMake should remain the compatibility path for that.\nBut vix.app is different.\nIt is narrow and declarative.\nIt has no arbitrary control flow.\nIt describes one target.\nThat makes it possible for Vix to translate it directly into native build tasks.
\n
Compatibility path vs native path
\n
The clean architecture is:
\n
CMakeLists.txt -> compatibility path\nvix.app -> native fast path
This does not mean removing CMake.\nIt means Vix should use the best path for each project type.\nFor complex projects:
\n
use CMake
For simple vix.app projects:
\n
use native BuildGraph
This gives Vix a realistic path to faster builds without breaking existing C++ workflows.
\n
The first native build target
\n
The first native vix.app build should support a small, clear subset.\nMinimum useful support:
These dependency files are required for correct incremental builds.\nWithout them, Vix cannot know which headers affect which object files.\nThe native path should treat dependency files as first-class build metadata.
\n
Dirty checking
\n
Before running a compile task, Vix should decide whether it is dirty.\nInputs include:
The compile tasks can run in parallel.\nThe link task waits for object files.\nThis is the same basic model as Ninja, but controlled by Vix for the manifest subset it understands.
\n
Link task generation
\n
For an executable target, Vix creates a link task.
\n
Inputs:
\n
object files\nlibraries\nlink options\npackage link targets or library names
Output:
\n
executable
For a static library target, Vix creates an archive task.\nFor a shared library target, Vix creates a shared link task.
But it still must respect platform and compiler differences.
\n
Relationship with CMake compatibility
\n
Native mode should not remove the CMake path.\nThe relationship should be:
\n
native path:\n faster for supported vix.app projects\n\ngenerated CMake path:\n fallback for unsupported vix.app features\n\nCMakeLists.txt path:\n full compatibility for advanced projects
This gives users both speed and safety.
\n
Relationship with vix run
\n
vix run should not care whether the project was built through CMake or native mode.
\n
It should ask:
\n
what is the target name?\nwhere is the build output?\nwhere is the executable?
If native mode preserves the same output layout, vix run can work unchanged or with minimal changes.
\n
Relationship with diagnostics
\n
Native mode gives Vix more control over diagnostics.\nInstead of receiving errors only through CMake/Ninja output, Vix can know:
\n
which task failed\nwhich source file was compiling\nwhich command was run\nwhich dependency triggered the task\nwhich cache key missed
This can make errors easier to explain.
\n
Explaining rebuilds
\n
A native build engine can eventually answer:
\n
why did this rebuild?
Examples:
\n
src/app.cpp rebuilt because source changed\nsrc/main.cpp rebuilt because include/config.hpp changed\nmyapp relinked because app.o changed\nassets copied because assets/logo.png changed
This is a major advantage of owning the graph.
\n
No-op native builds
\n
A native no-op build can be extremely fast.\nIf Vix knows:
Trying to do everything at once is risky.\nThe correct approach is layered.\nEach milestone should produce a working build.
\n
Engineering principle
\n
The principle should be:
\n
native where Vix can be correct\nfallback where CMake is safer
This keeps the user experience stable.\nIt also allows Vix to grow without breaking existing workflows.
\n
What success looks like
\n
For a supported vix.app project, success looks like this:
\n
first build:\n compile sources\n link target\n store cache\n\nsecond build:\n no work\n\none source changed:\n compile one file\n relink\n\nheader changed:\n compile affected files\n relink\n\nclean build with warm cache:\n restore objects\n relink or restore artifact
vix.app\n -> native path\n -> CMake fallback when needed
Conclusion
\n
Native vix.app builds are the natural next step for Vix.\nGenerated CMake makes vix.app usable today.\nNative BuildGraph execution can make it faster tomorrow.\nThe key is not to remove CMake.\nThe key is to use CMake where it is strongest and use Vix’s own graph where the project is simple enough to understand directly.\nThat gives Vix a realistic and powerful direction:
\n
CMakeLists.txt -> compatibility\nvix.app -> native fast path
The user keeps one command:
\n
vix build
But Vix gains the freedom to choose the best execution engine underneath.
\n';
+const towardNativeVixAppBuilds = {
+ html
+};
+export {
+ towardNativeVixAppBuilds as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.0.0-jikc9_3s.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.0.0-jikc9_3s.js
new file mode 100644
index 000000000..9d7379fa9
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.0.0-jikc9_3s.js
@@ -0,0 +1,8 @@
+const html = "
Vix.cpp v2.0.0
\n
Vix.cpp v2.0.0 marks the beginning of the V2 series.\nThis release is not a cosmetic version bump. It is the architectural reset that moves Vix away from the limitations of the V1 runtime and establishes a cleaner foundation for the future of the project.\nThe most important change is the removal of the old Boost.Beast-based HTTP layer and the introduction of a native vix::http stack built around the Vix async execution model.
\n
Why V2 was necessary
\n
Vix.cpp V1 was originally built around Boost.Beast.\nAt the beginning, that was useful because Beast provided a mature HTTP foundation. It made it possible to move fast and build the first version of the runtime. But as Vix grew, the architecture started to expose a serious problem: the runtime was becoming too dependent on Beast’s internal model.\nHTTP headers, sessions, request handling, middleware, WebSocket integration, and even parts of the application lifecycle started to feel like they were shaped by Beast instead of by Vix.\nThat made the project harder to control.\nVix was supposed to become a native C++ runtime with its own execution model, its own developer experience, and its own module boundaries. But with Beast deeply present across the codebase, Vix was slowly becoming a Beast-based application instead of an independent runtime.\nThis created several issues:
\n
\n
the HTTP layer was difficult to control deeply
\n
Boost headers leaked too far into the architecture
\n
installation and packaging became harder
\n
module boundaries were less clean
\n
WebSocket and middleware behavior depended too much on the old HTTP layer
\n
runtime shutdown was harder to reason about
\n
cross-platform builds were more fragile
\n
future runtime features were blocked by external architectural constraints
\n
\n
Vix.cpp v2.0.0 exists because those problems could not be solved cleanly with small patches.\nThe runtime needed a new foundation.
\n
Release focus
\n
The main focus of Vix.cpp v2.0.0 is architectural independence.\nThe old Boost.Beast-based HTTP layer has been removed and replaced with a native vix::http stack. This gives Vix direct ownership over request parsing, response handling, listener behavior, routing integration, middleware flow, shutdown logic, and runtime execution.\nThis change matters because Vix can now evolve around its own architecture instead of adapting every internal decision to Beast.\nThe goal is not only to remove Boost.Beast as a dependency. The goal is to make HTTP, WebSocket, middleware, and application runtime behavior share one coherent foundation.
\n
From Beast-driven to Vix-driven
\n
In V1, too many parts of the runtime were coupled to the Beast model.\nThat made the code harder to extend because changes in the HTTP layer could affect unrelated systems. Middleware, WebSocket, and server lifecycle behavior had to follow the old transport assumptions. This reduced flexibility and made it harder to design Vix as a general runtime.\nVix.cpp v2.0.0 changes that direction.\nThe runtime is now Vix-driven. The HTTP stack is native. The async model is central. The runtime executor owns the execution flow. Modules can integrate through Vix abstractions instead of depending on Beast-specific details.\nThis is the real reason V2 matters.\nIt gives Vix control over its own future.
\n
Native HTTP stack
\n
Vix.cpp v2.0.0 introduces the native vix::http stack.\nThis new stack replaces the old Boost.Beast-based implementation and becomes the foundation for HTTP server behavior in Vix.\nThe native stack makes the runtime easier to reason about because the core HTTP flow is now designed for Vix directly. Listener startup, accept loop behavior, request handling, response generation, and shutdown can now follow the same internal model as the rest of the runtime.\nThis is especially important for future work around performance, diagnostics, middleware, WebSocket behavior, documentation generation, and runtime tooling.\nA runtime cannot stay clean if its most central layer is controlled by an external abstraction that leaks everywhere.
\n
Async-first runtime architecture
\n
Vix.cpp v2.0.0 moves the runtime toward an async-first model.\nThe listener lifecycle is more deterministic, the accept loop shutdown is cleaner, and runtime execution is safer during application shutdown.\nThis release also improves shutdown behavior around App::close, worker cleanup, normal EOF handling, and unsafe runtime termination paths.\nThese details matter because server shutdown is one of the hardest parts of runtime design. A backend runtime must handle active connections, stopped listeners, pending tasks, worker threads, and cleanup order without leaving the system in an unsafe state.\nThe V2 architecture gives Vix a better foundation for that.
\n
RuntimeExecutor
\n
Vix.cpp v2.0.0 replaces legacy executor behavior with RuntimeExecutor.\nThis is part of the broader move toward a clearer runtime execution model.\nInstead of letting execution behavior remain scattered across older internal patterns, Vix now starts consolidating runtime lifecycle and execution responsibilities into a more explicit foundation.\nThis makes the runtime easier to extend and easier to debug.
\n
WebSocket and middleware migration
\n
The WebSocket and middleware layers were migrated to the new native HTTP stack.\nThis is a major internal change because WebSocket and middleware should not behave like separate systems with separate lifecycle rules. They need to share the same server foundation, the same runtime execution model, and the same shutdown behavior.\nIn V1, the old Boost.Beast-based layer made that harder. Vix had to adapt WebSocket and middleware behavior around Beast-driven internals.\nIn V2, these modules are aligned with the native Vix HTTP stack.\nThat creates a cleaner path for future improvements in real-time applications, middleware pipelines, routing, API documentation, and runtime diagnostics.
\n
Packaging and installation motivation
\n
One of the biggest motivations behind Vix.cpp v2.0.0 is installation simplicity.\nThe V1 architecture made packaging harder because Boost.Beast and related Boost dependencies were deeply connected to the runtime. This created friction for users who wanted to install Vix, build examples, or consume it as a reusable C++ toolchain.\nVix.cpp v2.0.0 removes that pressure by moving toward a Boost-free runtime foundation.\nThis does not only make the dependency graph cleaner. It also makes the project easier to distribute, easier to build, easier to debug, and easier to evolve.\nFor a C++ runtime, installation is part of the product. If the dependency model is too heavy or too fragile, adoption becomes harder.\nV2 fixes the foundation.
\n
Examples and ecosystem cleanup
\n
Vix.cpp v2.0.0 also reorganizes examples across HTTP, cache, P2P, sync, templates, database, ORM, and middleware.\nOlder CRUD-style examples and deprecated demo layouts were removed or replaced with cleaner, more progressive examples.\nThis cleanup matters because examples should teach the current architecture, not preserve old design assumptions.\nThe objective is to make the ecosystem easier to learn while keeping examples close to real usage patterns.
\n
Cross-platform stability
\n
This release improves Windows and MSVC compatibility across CLI, core, and middleware.\nIt also reduces MSVC-specific portability issues, improves environment variable handling, adds fallback behavior for Unicode rendering in terminal output on Windows, and improves formatting stability in the format module.\nThese changes are part of making Vix more serious as a cross-platform runtime.\nA runtime architecture is not complete if it only works well on one platform.
\n
Highlights
\n
\n
Introduced the native vix::http stack.
\n
Removed the old Boost.Beast-based HTTP layer.
\n
Removed related Boost compatibility paths.
\n
Started the Boost-free runtime foundation.
\n
Replaced legacy executor behavior with RuntimeExecutor.
\n
Improved async HTTP listener startup.
\n
Improved runtime executor and shutdown safety.
\n
Improved App::close shutdown behavior.
\n
Improved worker cleanup and normal EOF handling.
\n
Migrated WebSocket to the native HTTP layer.
\n
Migrated middleware to the native HTTP layer.
\n
Reorganized examples across HTTP, cache, P2P, sync, templates, database, ORM, and middleware.
\n
Removed older deprecated demo layouts.
\n
Improved Windows and MSVC compatibility.
\n
Improved internal consistency across modules.
\n
\n
Breaking changes
\n
Vix.cpp v2.0.0 introduces breaking architectural changes.\nThe old Boost.Beast-based HTTP stack has been removed.\nRelated Boost compatibility paths have also been removed.\nLegacy executor behavior has been replaced with RuntimeExecutor.\nListener startup behavior now follows the new async-first runtime model.\nProjects depending directly on old Beast-based internals must migrate to the new Vix-native HTTP and runtime APIs.
\n
Compatibility
\n
Vix.cpp v2.0.0 is the first official V2 baseline.\nIt is designed as a clean foundation for future V2 releases, not as a small compatibility patch for V1 internals.\nExisting projects using high-level Vix APIs should migrate toward the new native runtime model.\nProjects that depended on Boost.Beast-specific behavior or headers should update their integration to use Vix-owned abstractions instead.
\n
Stability
\n
This release fixes Windows build blockers across CLI, core, and middleware.\nIt reduces MSVC-specific portability issues.\nIt fixes ambiguous std::to_string usage in the template module.\nIt improves environment variable handling for cross-platform support.\nIt adds fallback behavior for Unicode rendering in terminal output on Windows.\nIt improves formatting stability and safety in the format module.
\n
Notes
\n
Vix.cpp v2.0.0 is the real foundation of the V2 series.\nThis release exists because V1 reached the architectural limit of the Boost.Beast-based design. Beast helped Vix start, but it also made the runtime harder to control, harder to package, and harder to evolve as an independent system.\nV2 resets that foundation.\nVix now has a native HTTP stack, a cleaner async-first architecture, better runtime ownership, cleaner module boundaries, and a stronger path toward becoming a complete C++ application runtime.\nThis was not a change for the sake of changing.\nIt was the necessary step to make Vix independent, installable, maintainable, and ready for the next stage of the ecosystem.
\n";
+const v2_0_0 = {
+ html
+};
+export {
+ v2_0_0 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.0-CpcIKkYM.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.0-CpcIKkYM.js
new file mode 100644
index 000000000..afd3aaee0
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.0-CpcIKkYM.js
@@ -0,0 +1,8 @@
+const html = "
Vix.cpp v2.1.0
\n
Vix.cpp v2.1.0 is a major performance, documentation, and ecosystem maturity release.\nThis release improves the HTTP hot path, scheduler behavior, async coroutine execution, template examples, documentation structure, and real-world examples across the Vix ecosystem.\nThe focus of this release is maturity. Vix is no longer only fast. It is becoming structured, documented, and ready to be used in real projects.
\n
Runtime performance
\n
Vix.cpp v2.1.0 improves performance in the core runtime.\nThe HTTP hot path was optimized, scheduler behavior was improved, run queue processing overhead was reduced, and the async coroutine fast path was cleaned up.\nThe async layer also removes redundant error handling where it was adding unnecessary overhead.\nThe result is lower latency, better throughput, and more predictable execution under load.\nFor a C++ runtime, performance is not only about raw speed. It is also about reducing unnecessary work in the most frequently executed paths.
\n
Scheduler and async execution
\n
This release improves the scheduler and task execution model.\nThe goal is to make async execution more efficient and more predictable, especially when the runtime is under load.\nReducing overhead in queue processing and coroutine dispatch helps Vix behave more consistently in HTTP and backend workloads.\nThis is important because the scheduler is part of the runtime foundation. Every higher-level module depends on the cost and reliability of task execution.
\n
Template system improvements
\n
Vix.cpp v2.1.0 includes a complete refactor of template examples.\nThe template module now focuses more on real-world use cases instead of isolated demonstrations.\nNew examples include:
\n
\n
shop dashboards
\n
blog home pages
\n
blog post pages
\n
admin dashboards
\n
marketing landing pages
\n
\n
The layout system is also improved with support for patterns such as extends, includes, and filters.\nThis makes the template module easier to understand through practical examples that look closer to real application pages.
\n
Real-world examples
\n
This release adds structured template examples with a progressive learning path.\nThe examples are organized to move from simple usage toward more complete scenarios.\nOlder and unstructured template demos were removed to keep the examples cleaner and easier to follow.\nThis matters because examples are not secondary content. They teach the architecture, the API style, and the intended usage patterns of the framework.
\n
Documentation expansion
\n
Vix.cpp v2.1.0 adds a large amount of documentation across the ecosystem.\nThe new documentation covers:
\n
\n
core modules
\n
async
\n
cache
\n
P2P
\n
sync
\n
middleware
\n
HTTP
\n
database
\n
ORM
\n
\n
The documentation also includes more real-world scenarios such as authentication, JWT, caching, and rate limiting.\nThe goal is to give developers a clearer mental model of Vix architecture and make onboarding easier.
\n
Developer experience
\n
This release improves the developer experience by aligning documentation, examples, and runtime behavior.\nExamples now follow a more progressive learning path.\nDocumentation is closer to real usage patterns.\nBasic and advanced concepts are separated more clearly.\nThis helps developers learn Vix without being forced to jump immediately into complex internals.
\n
Core and module consistency
\n
Vix.cpp v2.1.0 improves internal consistency across the core, async, and template modules.\nThe structure is cleaner and easier to maintain.\nThis prepares the codebase for future features by reducing inconsistency in areas that are used by many parts of the ecosystem.
\n
Highlights
\n
\n
Optimized the HTTP hot path in the core runtime.
\n
Improved scheduler and task execution behavior.
\n
Reduced run queue processing overhead.
\n
Optimized the async coroutine fast path.
\n
Removed redundant error handling in the async layer.
\n
Refactored template examples.
\n
Added real-world template use cases.
\n
Improved layout support with extends, includes, and filters.
\n
Added shop dashboard examples.
\n
Added blog home and post page examples.
\n
Added admin dashboard examples.
\n
Added marketing landing page examples.
\n
Expanded documentation across core, async, cache, P2P, sync, middleware, HTTP, database, and ORM.
\n
Added real-world documentation for authentication, JWT, caching, and rate limiting.
\n
Added progressive examples across modules.
\n
Removed outdated and legacy template examples.
\n
Improved consistency across core, async, and template modules.
\n
\n
Compatibility
\n
Vix.cpp v2.1.0 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is improved runtime performance, better documentation, cleaner examples, and stronger ecosystem structure.\nProjects using the runtime should benefit from lower overhead and more predictable behavior under load.
\n
Notes
\n
Vix.cpp v2.1.0 marks a major step toward making Vix a complete developer platform.\nFrom performance to documentation to real-world examples, Vix is now designed to be learned, used, and extended.\nThis release strengthens the foundation for future work across runtime performance, backend development, templates, documentation, and developer tooling.
\n";
+const v2_1_0 = {
+ html
+};
+export {
+ v2_1_0 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.1-C84FUUEK.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.1-C84FUUEK.js
new file mode 100644
index 000000000..875bb06a7
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.1-C84FUUEK.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.1
\n
Vix.cpp v2.1.1 is a small but important registry and CMake stability release.\nThis release improves dependency resolution in vix install, stabilizes generated dependency loading order in .vix/vix_deps.cmake, and makes generated application CMake files safer when registry packages are added.\nThe focus of this release is package reliability. Vix projects should be able to install registry dependencies, generate CMake integration files, and build consistently even when packages use slightly different manifest formats.
\n
Dependency manifest compatibility
\n
The main fix in Vix.cpp v2.1.1 is support for the deps fallback when loading package manifests.\nvix install now correctly resolves dependencies declared using both:
\n
"dependencies"
and:
\n
"deps"
This improves compatibility with mixed package formats and ensures dependencies are resolved in the correct topological order.\nThe recommended field remains dependencies, but deps continues to be supported for compatibility.
\n
Stable dependency loading order
\n
This release fixes dependency loading order in:
\n
.vix/vix_deps.cmake
The generated CMake dependency file now loads packages in a safer order, preventing missing target errors when one package depends on another.\nFor example, if router depends on http, the generated CMake integration must ensure the lower-level dependency is available before the dependent package tries to link against it.\nThis is important because CMake target availability depends on load order. A correct dependency graph is not enough if the generated CMake file loads targets in the wrong sequence.
\n
Registry-safe generated CMake
\n
Vix.cpp v2.1.1 improves generated CMakeLists.txt files for application projects.\nGenerated CMake now safely includes:
\n
.vix/vix_deps.cmake
only when the file exists.\nThis allows developers to create a project, build it without registry packages, then add registry packages later without breaking the CMake configuration.\nThe generated CMake also introduces:
\n
vix_link_optional_targets(...)
This helper makes it easier to link optional registry libraries only when their targets are available.
\n
Inline guidance for registry packages
\n
Generated application CMake files now include clearer inline guidance for linking registry libraries.\nThis helps users understand where registry dependencies should be linked and how optional package targets should be handled.\nThat is useful because dependency installation and CMake linking are separate concepts. Installing a package does not automatically mean every application target should link against every installed library.\nVix.cpp v2.1.1 makes that boundary easier to understand.
\n
Consistency between install, build, and run
\n
This release improves consistency between:
\n
vix install\nvix build\nvix run
The dependency resolver, generated CMake files, and runtime build behavior now handle mixed package formats more reliably.\nThat matters because a package workflow should not behave differently depending on whether the user installs dependencies, builds the project, or runs the application.
\n
Highlights
\n
\n
Added deps fallback support when loading package manifests.
\n
Preserved support for the recommended dependencies field.
\n
Improved topological dependency ordering in vix install.
\n
Stabilized dependency loading order in .vix/vix_deps.cmake.
\n
Fixed missing target errors for dependent packages.
\n
Improved generated CMakeLists.txt safety for registry packages.
\n
Safely includes .vix/vix_deps.cmake only when present.
\n
Added vix_link_optional_targets(...).
\n
Added inline guidance for linking registry libraries.
\n
Improved resilience for mixed package formats.
\n
Improved consistency between vix install, vix build, and vix run.
\n
\n
Compatibility
\n
Vix.cpp v2.1.1 introduces no breaking changes.\nExisting projects remain compatible.\nPackage manifests should standardize on:
\n
"dependencies"
but the older deps field remains supported.\nProjects using the Vix registry with CMake should now behave more reliably, especially when dependencies depend on each other.
\n
Notes
\n
Vix.cpp v2.1.1 is a small release, but it fixes an important class of stability problems.\nRegistry packages must resolve in the correct order, generated CMake must load dependency targets safely, and application projects must remain buildable before and after packages are added.\nSmall release. Big stability upgrade.
\n';
+const v2_1_1 = {
+ html
+};
+export {
+ v2_1_1 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.10-DpANfYUq.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.10-DpANfYUq.js
new file mode 100644
index 000000000..055e85d0b
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.10-DpANfYUq.js
@@ -0,0 +1,8 @@
+const html = "
Vix.cpp v2.1.10
\n
Vix.cpp v2.1.10 is a cross-platform build stability release.\nThis release fixes Windows build failures caused by missing spdlog and fmt, improves dependency consistency across Linux, macOS, and Windows, ensures fmt is linked correctly for logging utilities, and removes unnecessary Boost dependencies.\nThe focus of this release is build reliability. A runtime ecosystem must build consistently across supported platforms before higher-level tooling can be trusted.
\n
Windows dependency resolution
\n
The main fix in Vix.cpp v2.1.10 is resolving Windows build failures caused by missing spdlog and fmt.\nThese dependencies are now included in the vcpkg manifest so Windows builds can resolve them correctly through the standard dependency path.\nThis matters because Windows builds often fail when dependencies are assumed to exist globally or are handled differently from Unix-based systems. Vix.cpp v2.1.10 makes the Windows dependency path explicit.
\n
fmt and logging utilities
\n
This release also ensures that fmt is correctly available as a direct dependency for logging utilities.\nThat is important because logging is used across many runtime and CLI components. If fmt is only available indirectly, builds can become fragile depending on module order, platform behavior, or package manager configuration.\nVix.cpp v2.1.10 makes the dependency relationship clearer.
\n
Cross-platform dependency consistency
\n
Dependency setup is now more consistent across the main supported platforms.\nLinux uses apt.\nmacOS uses brew.\nWindows uses vcpkg.\nThe goal is not to make every platform identical internally. The goal is to ensure each platform has a clear and reliable dependency installation path.\nThis release reduces platform-specific failures caused by missing or inconsistent dependency setup.
\n
Build reliability
\n
Vix.cpp v2.1.10 eliminates several build issues caused by dependency mismatch between platforms.\nThis improves confidence in release builds, CI builds, and local developer builds.\nFor a C++ project, cross-platform stability depends on more than source code portability. It also depends on reliable dependency declaration, package discovery, linking behavior, and CI environment setup.
\n
Boost dependency cleanup
\n
This release removes unnecessary Boost dependencies, including boost-system and boost-beast.\nThat simplification keeps the project dependency graph smaller and better aligned with the V2 direction of Vix.cpp.\nRemoving unnecessary dependencies also reduces packaging complexity and lowers the risk of platform-specific build failures.
\n
Highlights
\n
\n
Fixed Windows build failure caused by missing spdlog and fmt.
\n
Added spdlog and fmt to the vcpkg manifest.
\n
Ensured fmt is available as a direct dependency for logging utilities.
\n
Improved dependency consistency across Linux, macOS, and Windows.
\n
Unified platform dependency setup around apt, brew, and vcpkg.
\n
Improved build reliability across supported platforms.
\n
Removed unnecessary boost-system dependency.
\n
Removed unnecessary boost-beast dependency.
\n
Reduced platform-specific dependency issues.
\n
\n
Compatibility
\n
Vix.cpp v2.1.10 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is that Windows builds should now resolve required logging and formatting dependencies correctly through vcpkg.\nLinux, macOS, and Windows builds should now behave more consistently.
\n
Notes
\n
Vix.cpp v2.1.9 stabilized CMake and fmt integration, but Windows builds were still missing required dependencies.\nVix.cpp v2.1.10 completes that work by fixing the Windows dependency path and aligning dependency setup across Linux, macOS, and Windows.\nThis release is an important step toward stable cross-platform releases for the Vix ecosystem.
\n";
+const v2_1_10 = {
+ html
+};
+export {
+ v2_1_10 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.11-CyLIjFT-.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.11-CyLIjFT-.js
new file mode 100644
index 000000000..f1378fb41
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.11-CyLIjFT-.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.11
\n
Vix.cpp v2.1.11 is a major SDK packaging release.\nThis release introduces full SDK distribution across Linux, macOS, and Windows. Instead of shipping only CLI binaries, Vix now produces complete installable SDK artifacts with a standard layout containing bin, include, and lib.\nThe focus of this release is integration. Vix should not only be executable as a command-line tool. It should also be installable as a C++ SDK that other projects can consume.
\n
Full SDK packaging
\n
Vix.cpp v2.1.11 introduces a dedicated SDK release workflow.\nThe new SDK packaging system produces complete installable artifacts for the major supported platforms:
These artifacts are designed for real C++ integration workflows, not only CLI usage.\nA proper SDK needs headers, libraries, and binaries in a predictable layout. This release establishes that distribution model.
\n
Installable SDK layout
\n
SDK artifacts now contain the full installation layout:
\n
bin/\ninclude/\nlib/
This is an important shift from CLI-only releases.\nThe bin directory provides executable tools such as the vix CLI.\nThe include directory provides public headers for C++ consumers.\nThe lib directory provides compiled libraries and package metadata needed for linking.\nThis layout makes Vix more usable as a native C++ dependency in external projects.
\n
Windows SDK packaging
\n
This release fixes Windows SDK packaging.\nThe Windows workflow now performs a proper build, install, and zip packaging process using vcpkg and the CMake toolchain.\nThat matters because Windows packaging often has different dependency and toolchain behavior from Linux and macOS.\nVix.cpp v2.1.11 brings Windows closer to the same SDK distribution model used on the other platforms.
\n
Cross-platform build consistency
\n
The SDK build environments for Linux, macOS, and Windows were aligned to produce consistent SDK layouts.\nThis improves predictability for users and maintainers.\nA developer should not need to learn a different package structure for each operating system. The platform-specific archive format may differ, but the internal SDK layout should remain consistent.
\n
Release workflow separation
\n
Vix.cpp v2.1.11 separates CLI releases from SDK releases.\nThe release architecture now distinguishes between:
\n
release.yml\nsdk-release.yml
release.yml remains focused on CLI release artifacts.\nsdk-release.yml is dedicated to SDK packaging.\nThis separation makes the release process clearer and easier to maintain. CLI distribution and SDK distribution have different goals, so they should not be forced into the same workflow.
\n
Real-world integration path
\n
This release prepares Vix for real-world integration workflows.\nA C++ runtime ecosystem needs an SDK distribution model so external projects can install Vix, include its headers, link its libraries, and use its tooling without depending on the source repository layout.\nVix.cpp v2.1.11 establishes that foundation.
\n
Highlights
\n
\n
Added full SDK packaging across platforms.
\n
Added a dedicated SDK release workflow.
\n
Added installable SDK artifacts for Linux.
\n
Added installable SDK artifacts for macOS.
\n
Added installable SDK artifacts for Windows.
\n
Added SDK archives: vix-sdk-linux-x86_64.tar.gz, vix-sdk-macos-aarch64.tar.gz, and vix-sdk-windows-x86_64.zip.
\n
Added full SDK layout with bin, include, and lib.
\n
Fixed Windows SDK packaging.
\n
Added proper Windows build, install, and zip packaging.
\n
Integrated vcpkg and CMake toolchain usage for Windows SDK builds.
\n
Aligned dependency installation across Linux, macOS, and Windows SDK workflows.
\n
Separated CLI release workflow from SDK release workflow.
\n
Prepared Vix for external C++ integration workflows.
\n
\n
Compatibility
\n
Vix.cpp v2.1.11 introduces no breaking changes.\nExisting CLI releases remain supported.\nThe main difference is that Vix now has a separate SDK distribution path in addition to CLI releases.\nDevelopers who only need the vix command can continue using CLI artifacts. Developers who want to integrate Vix into C++ projects can use the SDK artifacts.
\n
Notes
\n
Vix.cpp v2.1.10 stabilized builds across platforms.\nVix.cpp v2.1.11 introduces the complete SDK distribution model.\nThis release is important because it moves Vix beyond a CLI-centered release process and prepares it for real C++ adoption as an installable runtime SDK.
\n';
+const v2_1_11 = {
+ html
+};
+export {
+ v2_1_11 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.12-BCQMx7cH.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.12-BCQMx7cH.js
new file mode 100644
index 000000000..14ae44adf
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.12-BCQMx7cH.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.12
\n
Vix.cpp v2.1.12 is an SDK stabilization and CMake export reliability release.\nThis release makes nlohmann_json integration export-safe, normalizes SQLite target usage in the WebSocket module, fixes install(EXPORT VixTargets) issues, and improves the reliability of installed Vix SDK artifacts across Linux, macOS, and Windows.
\n
The focus of this release is installability. Vix should not only build correctly from source. It should also install as a reusable SDK and work reliably through find_package(Vix) in consumer projects.
\n
Export-safe JSON integration
\n
The main fix in Vix.cpp v2.1.12 is making nlohmann_json integration export-safe.\nPrevious JSON integration could expose non-exported targets through the installed package graph. That could cause CMake export failures or break consumer projects after installation.\nVix.cpp v2.1.12 removes direct linkage to non-exported JSON targets and ensures the header-only fallback works correctly with install and export flows.\nThis makes the JSON module safer to consume through installed SDK packages.
\n
SQLite target normalization
\n
The WebSocket module now uses normalized SQLite target handling.\nThis release replaces deprecated usage of:
\n
SQLite::SQLite3
with the canonical target:
\n
SQLite3::SQLite3
Compatibility aliases are also added for cross-platform builds.\nThis matters because SQLite target names can vary depending on the platform, package manager, and CMake version. A reliable SDK must normalize those differences internally instead of pushing them onto users.
\n
CMake export fixes
\n
Vix.cpp v2.1.12 fixes install(EXPORT VixTargets) issues caused by non-exported dependencies.\nThis is a critical part of SDK packaging. A project may compile correctly in the source tree but fail when installed if exported targets reference dependencies that were never exported or cannot be resolved by the consumer.\nThis release strengthens the export graph so installed Vix packages are usable through:
\n
find_package(Vix)
SDK installability
\n
This release improves SDK installability.\nGenerated SDK artifacts are now fully usable after installation without missing dependencies from JSON or SQLite backends.\nThis is important for developers who want to install Vix once and consume it from separate projects instead of always working inside the Vix source tree.\nVix.cpp v2.1.12 makes that workflow more reliable.
\n
Cross-platform dependency consistency
\n
Dependency handling is now more consistent across Linux, macOS, and Windows.\nThis applies especially to SQLite and JSON backends, where package discovery and target naming can differ between environments.\nVix.cpp v2.1.12 improves those paths so the same installed SDK behaves more predictably across platforms.
\n
Highlights
\n
\n
Made nlohmann_json integration export-safe.
\n
Removed direct linkage to non-exported JSON targets.
\n
Fixed header-only JSON fallback behavior with install and export flows.
\n
Normalized SQLite target usage in the WebSocket module.
\n
Replaced deprecated SQLite::SQLite3 usage with SQLite3::SQLite3.
\n
Added SQLite compatibility aliases for cross-platform builds.
\n
Fixed install(EXPORT VixTargets) errors.
\n
Improved CMake package reliability.
\n
Improved find_package(Vix) usage for consumer projects.
\n
Improved SDK installability after artifact generation.
\n
Unified dependency handling across Linux, macOS, and Windows for SQLite and JSON backends.
\n
\n
Compatibility
\n
Vix.cpp v2.1.12 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is that installed SDK artifacts should now work more reliably through find_package(Vix) without missing JSON or SQLite dependency targets.\nProjects using WebSocket, JSON, or installed Vix SDK packages should benefit from more stable CMake configuration behavior.
\n
Notes
\n
Vix.cpp v2.1.11 introduced SDK packaging.\nVix.cpp v2.1.12 stabilizes the CMake export layer and makes Vix more reliable as a reusable installed SDK.\nThis release is important because a C++ runtime ecosystem must be installable, export-safe, and consumable outside its own source tree. The SDK should work as a real package, not only as a local build.
\n';
+const v2_1_12 = {
+ html
+};
+export {
+ v2_1_12 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.13-DGbDu20Y.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.13-DGbDu20Y.js
new file mode 100644
index 000000000..5639b3e77
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.13-DGbDu20Y.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.13
\n
Vix.cpp v2.1.13 is an SDK packaging and CMake export reliability release.\nThis release fixes the cache module’s nlohmann_json integration, corrects FetchContent usage order, improves header-only fallback handling, and completes the export-safe packaging work needed for reliable SDK installation across modules.\nThe focus of this release is export correctness. A module can build correctly inside the source tree and still fail when installed if its dependency model leaks non-exported targets or build-only paths.
\n
Export-safe nlohmann_json integration
\n
The main fix in Vix.cpp v2.1.13 is making the cache module’s nlohmann_json integration export-safe.\nThe previous integration could link against FetchContent-created targets in a way that was valid during the build but invalid during installation and package export.\nThat could break:
\n
install(EXPORT VixTargets ...)
Vix.cpp v2.1.13 removes invalid linkage to FetchContent targets and ensures the header-only fallback does not leak into exported package metadata incorrectly.
\n
Correct FetchContent usage order
\n
This release also fixes the FetchContent call sequence used for nlohmann_json.\nThe previous order could cause configuration errors such as:
\n
No content details recorded for nlohmann_json
That kind of failure is easy to miss during local development but can break clean CI builds, SDK packaging, and fresh consumer environments.\nVix.cpp v2.1.13 corrects the sequence so fallback dependency handling behaves consistently.
\n
Header-only fallback handling
\n
The cache module now handles header-only fallback includes more carefully.\nFallback JSON headers are exposed only at build time and are not exported as external targets.\nThis distinction is important in CMake packaging. Build-tree usage and install-tree usage are not the same thing.\nA dependency path that is valid while compiling Vix may not be valid after the SDK is installed elsewhere.
\n
SDK install reliability
\n
This release improves SDK installation reliability for the cache module in both static and header-only modes.\nThe module can now install correctly without missing dependencies or leaking invalid external targets.\nThis is an important step for users who consume Vix as an installed SDK instead of building everything from the source tree.
\n
CMake export consistency
\n
Vix.cpp v2.1.13 improves CMake export consistency across modules.\nAll modules now follow a more consistent pattern for handling external dependencies in export sets.\nThis reduces the risk that one module solves dependency handling differently from another module and accidentally breaks installed package usage.\nFor a modular C++ ecosystem, consistency in export behavior is not optional. It is required for downstream reliability.
\n
Fallback dependency handling
\n
JSON fallback handling is also improved.\nWhen a system package is not available, the fallback dependency is handled correctly and installed with the SDK when needed.\nThis makes the SDK more portable in environments where users do not have every dependency installed globally.
\n
Highlights
\n
\n
Made nlohmann_json integration export-safe in the cache module.
\n
Removed invalid linkage to FetchContent targets.
\n
Fixed install(EXPORT VixTargets ...) failures caused by cache dependency handling.
\n
Corrected FetchContent usage order.
\n
Fixed No content details recorded for nlohmann_json configure errors.
\n
Improved header-only fallback include handling.
\n
Ensured fallback JSON headers are build-time only when appropriate.
\n
Improved SDK install reliability in static and header-only modes.
\n
Improved CMake export consistency across modules.
\n
Improved fallback dependency handling when system JSON packages are unavailable.
\n
Finalized export-safe SDK packaging across modules.
\n
\n
Compatibility
\n
Vix.cpp v2.1.13 introduces no breaking changes.\nExisting users of the cache module remain compatible.\nThe main difference is that SDK installation and exported package usage should now be more reliable, especially when nlohmann_json is provided through fallback handling instead of a system package.
\n
Notes
\n
Vix.cpp v2.1.12 stabilized JSON and SQLite integration.\nVix.cpp v2.1.13 completes the follow-up work for the cache module and finalizes export-safe SDK packaging across the affected modules.\nThis release is important because C++ package exports must work outside the original build tree. Vix modules should be usable after installation without leaking internal FetchContent targets, temporary include paths, or incomplete dependency metadata.
\n';
+const v2_1_13 = {
+ html
+};
+export {
+ v2_1_13 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.14-BbTcR3sE.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.14-BbTcR3sE.js
new file mode 100644
index 000000000..bc16c61c9
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.14-BbTcR3sE.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.14
\n
Vix.cpp v2.1.14 is a module dependency cleanup release.\nThis release removes direct nlohmann_json linkage from the cache module, fixes VixTargets export errors caused by leaked third-party dependencies, and reinforces vix::json as the unified JSON abstraction across the ecosystem.\nThe focus of this release is clean module boundaries. A Vix module should depend on Vix-owned public abstractions, not expose third-party implementation details through installed package exports.
\n
Unified JSON abstraction
\n
The main change in Vix.cpp v2.1.14 is that the cache module now relies on vix::json instead of linking directly to:
\n
nlohmann_json::nlohmann_json
This keeps JSON usage consistent across modules.\nvix::json becomes the single JSON entry point, which improves portability and gives Vix better control over the public dependency model.\nFor a modular C++ runtime, this matters because third-party dependencies should not leak accidentally from internal modules into downstream consumer projects.
\n
VixTargets export fix
\n
This release fixes an install(EXPORT VixTargets ...) failure caused by non-exported external dependencies leaking from the cache module.\nThat kind of failure is especially important because it affects installed SDK usage. A project may build correctly inside the source tree but fail once exported and consumed through find_package(Vix).\nVix.cpp v2.1.14 fixes that by ensuring the cache module no longer exposes local third-party JSON targets through the exported package graph.
\n
Cleaner umbrella dependency architecture
\n
The cache module no longer performs local JSON resolution or FetchContent logic.\nDependency responsibility is delegated to the json module.\nThis aligns the module with umbrella build principles: each module should own its own dependency responsibilities, and other modules should consume the Vix-facing abstraction.\nThat prevents duplicated dependency management and makes the package export graph easier to reason about.
\n
Cache module cleanup
\n
Internally, the cache module removes local nlohmann_json detection and fallback logic.\nThis simplifies the module and reduces the risk of conflicting dependency resolution paths.\nThe result is a cleaner cache module that depends on the Vix JSON layer instead of managing JSON independently.
\n
Highlights
\n
\n
Removed direct nlohmann_json dependency from the cache module.
\n
Replaced direct JSON linkage with vix::json.
\n
Fixed VixTargets export errors caused by leaked external dependencies.
\n
Enforced vix::json as the unified JSON abstraction.
\n
Removed local JSON resolution from the cache module.
Delegated JSON dependency responsibility to the json module.
\n
Improved umbrella dependency architecture.
\n
Prevented accidental export of third-party JSON targets.
\n
Strengthened module separation between cache and JSON.
\n
\n
Compatibility
\n
Vix.cpp v2.1.14 introduces no breaking changes.\nExisting cache users remain compatible.\nThe main difference is internal dependency cleanup: cache now uses vix::json as the JSON abstraction instead of exposing direct nlohmann_json linkage.\nInstalled package exports should now behave more reliably when consumed through find_package(Vix).
\n
Notes
\n
Vix.cpp v2.1.14 is a small but important architecture release.\nIt does not add user-facing runtime features. It fixes the dependency model behind the cache module and ensures JSON usage flows through the Vix abstraction layer.\nThis kind of cleanup is essential for a modular C++ ecosystem because package exports must remain clean, stable, and free from accidental third-party target leakage.
\n';
+const v2_1_14 = {
+ html
+};
+export {
+ v2_1_14 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.15-DvHfhAD8.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.15-DvHfhAD8.js
new file mode 100644
index 000000000..9a95c7cf9
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.15-DvHfhAD8.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.15
\n
Vix.cpp v2.1.15 is an SDK installation and runtime portability release.\nThis release fixes relative runtime library resolution for the SDK binary, improves installer behavior when the CLI is already installed at the target location, enhances installer output across Linux, macOS, and Windows, and makes the SDK runtime more self-contained.\nThe focus of this release is installation reliability. A C++ SDK should not only build correctly. It should also install cleanly, locate its runtime libraries, and give users clear feedback during setup.
\n
Relative RPATH for SDK binaries
\n
The main fix in Vix.cpp v2.1.15 is relative RPATH support for the SDK binary.\nThe vix executable can now locate its shared libraries relative to its install prefix.\nOn Unix systems, the runtime path uses:
\n
$ORIGIN/../lib
On macOS, it uses:
\n
@loader_path/../lib
This improves SDK portability because the executable no longer depends on users manually configuring library paths after installation.
\n
Self-contained SDK runtime
\n
This release refactors the CLI so it resolves dependencies relative to its installation prefix.\nThat makes the SDK runtime more self-contained and reduces the need for manual environment configuration.\nFor developers, this is important because an installed CLI should behave predictably after installation. If the binary exists but cannot locate its shared libraries, the installation is effectively broken.\nVix.cpp v2.1.15 strengthens that path.
\n
Same-file symlink handling
\n
The installer now handles same-file symlink cases in SDK mode.\nThis prevents the installer from attempting to create a symbolic link when the CLI is already installed at the target location.\nThat small edge case matters because repeated installations should be safe. A user should be able to rerun the installer without hitting avoidable file or symlink errors.
\n
Installer experience
\n
Vix.cpp v2.1.15 improves the installer experience on Linux and macOS.\nThe installer now uses clearer step-based output with styled messages for steps, success states, and warnings.\nThis makes installation feel more professional and easier to follow.\nInstead of a raw script-like output, users now get a clearer progression of what is happening and whether the installation completed successfully.
\n
Windows installer output
\n
The Windows installer output was also improved.\nThis release adds structured logs and better feedback during installation, including clearer success and warning messages.\nThe goal is to make installation feedback consistent across platforms, while still respecting platform-specific behavior.
\n
Installation summary
\n
The installer now displays a better final summary after completion.
\n
The summary includes:
\n
\n
final install location
\n
installed version
\n
install kind
\n
\n
This gives users immediate confirmation of what was installed and where it was placed.
\n
Cleaner install flow
\n
Internally, the installer logic was simplified and logging was unified across platforms.\nThis reduces duplicated behavior and makes future installer improvements easier to maintain.\nInstallation is part of the product experience. A clean installer flow helps Vix feel more reliable before the user even runs their first project.
\n
Highlights
\n
\n
Added relative RPATH support for the SDK binary.
\n
Added $ORIGIN/../lib runtime path support on Unix.
\n
Added @loader_path/../lib runtime path support on macOS.
\n
Fixed SDK binary shared library lookup after installation.
\n
Fixed same-file symlink handling in SDK mode.
\n
Improved Linux installer output.
\n
Improved macOS installer output.
\n
Improved Windows installer output.
\n
Added clearer step-based installer logs.
\n
Added styled success and warning messages.
\n
Added a better installation summary.
\n
Displayed final location, version, and install kind after installation.
\n
Made the SDK runtime more self-contained.
\n
Simplified installer flow and unified logging across platforms.
\n
\n
Compatibility
\n
Vix.cpp v2.1.15 introduces no breaking changes.\nExisting SDK installations remain compatible.\nThe main difference is that new SDK installations should locate their runtime libraries more reliably after installation.\nRepeated installation in SDK mode should also behave more safely when the CLI already exists at the target location.
\n
Notes
\n
Vix.cpp v2.1.15 is a release engineering and installer quality update.\nIt does not introduce new runtime APIs. It focuses on making the installed SDK easier to use, easier to relocate, and easier to trust across Linux, macOS, and Windows.\nThis is an important step for Vix.cpp because the developer experience starts at installation, not at the first command.
\n';
+const v2_1_15 = {
+ html
+};
+export {
+ v2_1_15 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.16-Dfg4IRBW.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.16-Dfg4IRBW.js
new file mode 100644
index 000000000..29877222a
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.16-Dfg4IRBW.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.16
\n
Vix.cpp v2.1.16 is a Linux release portability and SDK compatibility release.\nThis release fixes runtime failures caused by shared library ABI mismatches in Linux artifacts, updates release and SDK workflows to build on Ubuntu 24.04, improves fmt and spdlog linkage behavior, and adds runtime validation for packaged Linux artifacts.\nThe focus of this release is making released Vix binaries more reliable on modern Linux systems.
\n
Linux runtime compatibility
\n
The main fix in Vix.cpp v2.1.16 is resolving Linux runtime failures caused by shared library ABI mismatch.\nPrevious Linux artifacts were built on Ubuntu 22.04 and could be linked against older shared libraries such as:
\n
libfmt.so.8
On newer distributions such as Ubuntu 24.04, this could cause runtime failures after installation if the expected shared library ABI was not available.\nVix.cpp v2.1.16 updates release workflows to build on Ubuntu 24.04, aligning packaged artifacts with modern Linux environments.
\n
SDK artifact reliability
\n
This release also updates SDK artifact generation to use the same Linux build environment.\nThat matters because the SDK should not have different runtime assumptions from the CLI or release artifacts.\nBy unifying the Linux build environment, Vix reduces the chance that users install an SDK package that builds successfully but fails at runtime because of mismatched system library dependencies.
\n
Header-only fmt and spdlog usage
\n
Vix.cpp v2.1.16 improves vix_utils by preferring header-only targets for fmt and spdlog.
\n
The preferred targets are now:
\n
fmt::fmt-header-only
and:
\n
spdlog::spdlog_header_only
This reduces reliance on system shared libraries and improves portability for packaged releases.\nFor a distributed C++ CLI and SDK, depending accidentally on system-specific shared library versions can make binaries fragile. Header-only integration helps reduce that risk.
\n
Shared library dependency control
\n
This release also improves fmt and spdlog integration by adding:
\n
SPDLOG_FMT_EXTERNAL=1
This ensures more consistent integration with fmt and prevents unexpected linkage behavior.\nThe goal is to avoid implicit shared library dependencies in Linux release artifacts whenever possible.
\n
Packaged artifact validation
\n
Vix.cpp v2.1.16 adds a runtime validation step for packaged Linux artifacts.\nAfter packaging, the release workflow now validates the artifact by executing:
\n
vix --version
and inspecting dependencies through:
\n
ldd
This helps detect broken binaries before they are published.\nThis is important because a package can compile successfully and still fail on the target system due to missing or incompatible runtime dependencies.
\n
Unified Linux build environment
\n
The Linux release and SDK workflows are now standardized on Ubuntu 24.04.\nThis gives the release process a more consistent baseline and improves compatibility with modern Linux distributions.\nIt also reduces differences between release artifacts and SDK artifacts, which makes future debugging easier.
\n
Highlights
\n
\n
Fixed Linux runtime failures caused by shared library ABI mismatch.
\n
Updated Linux release workflows from Ubuntu 22.04 to Ubuntu 24.04.
\n
Improved compatibility with modern Linux distributions.
\n
Fixed SDK binary runtime behavior on modern Linux systems.
\n
Unified release and SDK Linux build environments.
\n
Updated vix_utils to prefer fmt::fmt-header-only.
\n
Updated vix_utils to prefer spdlog::spdlog_header_only.
\n
Reduced reliance on system shared libraries.
\n
Added SPDLOG_FMT_EXTERNAL=1.
\n
Improved control over implicit Linux shared library dependencies.
\n
Added packaged Linux artifact runtime validation.
\n
Added vix --version validation after packaging.
\n
Added ldd dependency inspection before publishing artifacts.
\n
\n
Compatibility
\n
Vix.cpp v2.1.16 introduces no breaking changes.\nExisting source builds remain compatible.\nExisting installations on older Linux systems may still require compatible runtime libraries.\nThis release improves compatibility for modern Linux systems, especially environments closer to Ubuntu 24.04.
\n
Notes
\n
Vix.cpp v2.1.16 is a release engineering stability update.\nIt does not introduce new runtime APIs. It focuses on making Linux artifacts and SDK packages safer to install and execute.\nFuture releases should continue moving toward fully self-contained Linux binaries, but this release already reduces avoidable runtime failures caused by shared library ABI mismatches.
\n';
+const v2_1_16 = {
+ html
+};
+export {
+ v2_1_16 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.17-2qTef-h4.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.17-2qTef-h4.js
new file mode 100644
index 000000000..54d013a55
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.17-2qTef-h4.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.17
\n
Vix.cpp v2.1.17 is a CMake package compatibility release focused on SQLite dependency resolution in exported WebSocket builds.\nThis release fixes a critical developer experience issue where vix::websocket could expose SQLite3::SQLite3 in exported package targets, while that target was not guaranteed to exist in the consumer project. The result could be a CMake configuration failure during find_package(Vix) or when running simple programs through vix run.
\n
SQLite target mismatch
\n
The main fix in Vix.cpp v2.1.17 is resolving the SQLite target mismatch in the exported WebSocket module.\nPreviously, vix::websocket could expose SQLite3::SQLite3 as a dependency, but consumer projects were not always guaranteed to have that imported target available. This caused package configuration failures even when SQLite itself was installed on the system.\nVix.cpp v2.1.17 improves this by ensuring the SQLite dependency is resolved before Vix targets are loaded.
\n
VixConfig.cmake dependency handling
\n
This release adds proper SQLite dependency handling in VixConfig.cmake.
\n
The package configuration now calls the required dependency discovery path before loading exported Vix targets. This prevents missing target errors during:
\n
find_package(Vix)
That matters because installed package usage must be reliable. A consumer project should not need to manually know the internal dependency order of Vix modules just to import the SDK.
\n
SQLite target normalization
\n
Vix.cpp v2.1.17 improves SQLite target naming across modules and package configuration.
\n
The release standardizes on:
\n
SQLite3::SQLite3
as the canonical SQLite target, while also adding compatibility aliases for common alternatives such as:
\n
SQLite::SQLite3
and:
\n
sqlite3
This makes the package more tolerant of different environments, package managers, and CMake discovery behavior.
\n
WebSocket dependency reliability
\n
The WebSocket module now has stronger SQLite target resolution logic.\nThis improves compatibility across environments such as vcpkg, system package installs, and manual SQLite installations. The goal is to make vix::websocket usable from installed Vix packages without requiring consumers to patch or normalize SQLite target names themselves.\nFor developers, the practical result is simpler: running programs that depend on WebSocket should no longer fail because of missing transitive SQLite targets.
\n
Developer experience
\n
This release eliminates a common vix run configuration failure.\nSimple programs should not fail because a transitive dependency from an exported module was not correctly resolved. Vix.cpp v2.1.17 strengthens that path so dependency discovery is handled by the package configuration instead of being pushed onto the user.\nThis is especially important for a runtime-focused CLI, where users expect vix run to handle the project environment consistently.
\n
Highlights
\n
\n
Fixed SQLite target mismatch in the exported WebSocket module.
\n
Fixed cases where vix::websocket exposed SQLite3::SQLite3 without guaranteeing the target existed.
\n
Added proper SQLite dependency resolution before loading Vix targets.
\n
Improved VixConfig.cmake dependency handling.
\n
Standardized SQLite target naming around SQLite3::SQLite3.
\n
Added compatibility aliases for SQLite::SQLite3 and sqlite3.
Improved support for vcpkg, system packages, and manual SQLite installs.
\n
Eliminated common vix run failures caused by missing transitive SQLite dependencies.
\n
\n
Compatibility
\n
Vix.cpp v2.1.17 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is that projects using modules with SQLite-backed dependencies, especially vix::websocket, should now configure more reliably through find_package(Vix) and vix run.
\n
Notes
\n
Vix.cpp v2.1.17 is a focused package reliability release.\nIt does not introduce new runtime features. It fixes an important dependency-resolution problem in exported WebSocket packages and makes SQLite target handling more robust across consumer environments.\nFor a C++ runtime ecosystem, this kind of fix is essential because package configuration must be predictable before higher-level workflows can feel reliable.
\n';
+const v2_1_17 = {
+ html
+};
+export {
+ v2_1_17 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.18-CBM0T0is.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.18-CBM0T0is.js
new file mode 100644
index 000000000..2c8a56f88
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.18-CBM0T0is.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.18
\n
Vix.cpp v2.1.18 is a package compatibility and dependency resolution patch release.\nThis release fixes SQLite target normalization across different CMake versions and resolves remaining vix run failures caused by exported WebSocket SQLite dependency handling.
\n
SQLite target compatibility
\n
The main fix in Vix.cpp v2.1.18 is more robust SQLite target handling in exported Vix packages.\nPrevious package configuration relied on fragile SQLite alias normalization. That could break depending on how CMake discovered SQLite and which imported target name was available in the consumer environment.\nVix.cpp v2.1.18 replaces that fragile behavior with imported compatibility targets.\nThis allows exported Vix packages to work reliably with both:
\n
SQLite::SQLite3
and:
\n
SQLite3::SQLite3
WebSocket SQLite dependency handling
\n
This release also fixes remaining vix run failures caused by exported WebSocket SQLite dependency handling.\nThe WebSocket module can depend on SQLite in package contexts. If the exported dependency graph does not normalize SQLite targets correctly, consumers may fail even when SQLite is installed and usable.
\n
Vix.cpp v2.1.18 strengthens this path so vix run can work more reliably when WebSocket and SQLite are involved through installed package exports.
\n
Consumer package compatibility
\n
This patch improves compatibility for projects using both older and newer CMake versions.\nThat matters because C++ package consumers do not always use the same CMake version, the same platform, or the same package discovery behavior.\nA Vix package export should be resilient enough to support those differences without forcing users to manually patch target names.
\n
Highlights
\n
\n
Fixed SQLite target normalization across CMake versions.
\n
Replaced fragile SQLite alias normalization with imported compatibility targets.
\n
Improved exported package compatibility with SQLite::SQLite3.
\n
Improved exported package compatibility with SQLite3::SQLite3.
\n
Fixed remaining vix run failures caused by exported WebSocket SQLite dependency handling.
\n
Strengthened package compatibility for consumers using older and newer CMake versions.
\n
\n
Compatibility
\n
Vix.cpp v2.1.18 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is that exported Vix packages should now resolve SQLite dependencies more reliably across different CMake versions and consumer environments.\nProjects using WebSocket features with SQLite-backed package exports should benefit from more stable vix run behavior.
\n
Notes
\n
Vix.cpp v2.1.18 is intentionally focused.\nIt does not add new runtime features. It strengthens package export reliability around SQLite target naming, WebSocket dependency handling, and consumer compatibility.\nThis kind of release is important for a C++ ecosystem because installed package behavior must remain reliable across platforms, package managers, and CMake versions.
\n';
+const v2_1_18 = {
+ html
+};
+export {
+ v2_1_18 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.19-D0LSLzui.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.19-D0LSLzui.js
new file mode 100644
index 000000000..4af625ab4
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.19-D0LSLzui.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.19
\n
Vix.cpp v2.1.19 is a build diagnostics and reliability release.\nThis release introduces structured CMake build error diagnostics, dedicated detectors for common build failures, cleaner CLI error output, more reliable --clean behavior, and safer publish handling in edge cases involving missing working directories or git context.\nThe focus of this release is making build failures easier to understand.\nC++ build systems can fail for many reasons: missing link targets, invalid CMake configuration, compilation errors, linker errors, stale build artifacts, or incorrect project roots. Vix.cpp v2.1.19 improves how these failures are detected and presented.
\n
Structured CMake diagnostics
\n
Vix.cpp v2.1.19 introduces a structured error detection system for CMake builds.\nInstead of passing through noisy raw build output as the main user experience, Vix now detects common failure patterns and turns them into clearer diagnostics.\nThis is important because raw CMake and Ninja output is often technically accurate but difficult to read quickly.\nA runtime-oriented CLI should help the developer understand what failed, where it failed, and what action is likely useful next.
\n
Dedicated build failure detectors
\n
This release adds dedicated detectors for common build issues.\nThe diagnostics now handle cases such as linking failures, missing targets, and compilation failures more explicitly.\nThis makes the build pipeline easier to debug because different error families can receive different messages and hints.\nA missing target should not be explained like a compiler syntax error.\nA linker failure should not be treated like a missing CMake project.\nVix.cpp v2.1.19 moves the error system toward that separation.
\n
Cleaner error readability
\n
Error output is now cleaner and easier to understand.\nNoisy lines such as:
\n
ninja: build stopped
are no longer treated as useful primary diagnostics.\nThose lines describe the consequence of a failure, not the cause.\nVix now focuses on the relevant part of the error first, reducing the amount of terminal noise developers must scan during debugging.
\n
Smarter hint system
\n
The hint system was improved so follow-up suggestions are only displayed when relevant.\nThis matters because an irrelevant hint can be worse than no hint. It can send the developer toward the wrong fix.\nVix.cpp v2.1.19 gates hints on handled errors, which prevents misleading suggestions from appearing when the error has already been correctly identified.\nThe result is a more disciplined diagnostic flow: detect the failure, classify it, show the focused message, and only add a hint when it helps.
\n
Reliable clean builds
\n
This release improves --clean behavior.\nThe command now correctly removes local build directories and build artifacts, ensuring a fresh build environment when requested.\nThis is important because stale CMake or Ninja artifacts can create confusing behavior.\nWhen a developer asks for a clean build, the CLI should remove the local build state reliably instead of leaving partial artifacts behind.
\n
Publish reliability
\n
Vix.cpp v2.1.19 also improves publish behavior.\nPublishing now handles null current working directory cases more safely and improves git detection.\nThese are edge cases, but they matter for reliability. CLI tools should behave predictably even when invoked from unusual environments, scripts, automation, or partially initialized project contexts.
\n
Highlights
\n
\n
Added structured CMake build error diagnostics.
\n
Added dedicated detectors for build failures.
\n
Added specialized handling for linking issues, missing targets, and compilation failures.
\n
Improved CLI error readability.
\n
Removed noisy build-stop lines from the main diagnostic path.
\n
Improved --clean behavior.
\n
Ensured clean builds remove local build directories and artifacts.
\n
Improved hint relevance.
\n
Gated hints on handled errors.
\n
Fixed missing CMake link target detection.
\n
Fixed incomplete cleanup when using --clean.
\n
Improved publish behavior for null working directory cases.
\n
Improved git detection during publish.
\n
\n
Compatibility
\n
Vix.cpp v2.1.19 introduces no breaking changes.\nExisting build, run, and publish workflows remain compatible.\nThe main difference is that build failures should now be reported with cleaner diagnostics and more focused hints.\nProjects using --clean should now get a more reliable fresh build environment.
\n
Notes
\n
Vix.cpp v2.1.19 is a focused diagnostic release.\nIt improves the developer experience around one of the most painful parts of C++ development: understanding why a build failed.\nThe long-term direction is clear. Vix should not only run C++ projects. It should also explain failures in a way that is precise, readable, and useful for real debugging.
\n';
+const v2_1_19 = {
+ html
+};
+export {
+ v2_1_19 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.2-BYpp0vxi.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.2-BYpp0vxi.js
new file mode 100644
index 000000000..f4abe6ca4
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.2-BYpp0vxi.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.2
\n
Vix.cpp v2.1.2 is a CLI usability and runtime output release.\nThis release adds bash shell completion, pagination support for search results, improved command suggestions, and better live runtime stdout behavior through PTY support in vix run.\nThe focus of this release is interaction quality. A developer tool should not only execute commands correctly. It should also make discovery, navigation, output, and command usage smoother.
\n
Shell completion
\n
Vix.cpp v2.1.2 adds a shell completion command for bash.\nThis allows users to generate auto-completion scripts for the Vix CLI, making command discovery and daily usage faster.\nShell completion is important because as the CLI grows, users should not need to memorize every command, flag, or subcommand. Completion turns the CLI itself into a more discoverable interface.
\n
Search pagination
\n
This release adds pagination support to search results.\nSearch commands now support:
\n
--page\n--limit
This improves usability when the result set is large.\nInstead of dumping too much output at once, Vix can now present search results in a more controlled way. This makes registry or package search workflows easier to read and easier to navigate.
\n
Live runtime output
\n
Vix.cpp v2.1.2 improves live runtime stdout behavior in vix run.\nThe command now uses PTY support for runtime output, which improves real-time display when running applications.\nThis matters for applications that print logs, prompts, status messages, or long-running output. The CLI should show output as the program produces it, not delay or buffer it in a way that makes runtime behavior harder to understand.
\n
Command suggestions
\n
Command suggestions were improved.\nSuggestions now rely on dispatcher entries, which makes them more accurate and better aligned with the actual registered command set.\nThis is important because suggestions should reflect what the CLI really supports. If suggestions are generated from a separate or outdated source, they can become misleading.
\n
Documentation
\n
This release adds a shell completion guide.\nThe new documentation explains how to enable and use CLI auto-completion.\nThat matters because shell completion is only useful if users can install and activate it easily in their environment.
\n
Developer experience
\n
Vix.cpp v2.1.2 improves the daily CLI experience by making commands easier to discover, search results easier to navigate, and runtime output easier to follow.\nThese changes are small individually, but together they make Vix feel more polished as a developer-facing tool.
\n
Highlights
\n
\n
Added bash shell completion generation.
\n
Added documentation for shell completion.
\n
Added search pagination support.
\n
Added --page support for search results.
\n
Added --limit support for search results.
\n
Improved live runtime stdout in vix run.
\n
Added PTY-based runtime output handling.
\n
Improved command suggestions.
\n
Updated suggestions to rely on dispatcher entries.
\n
Improved CLI interaction quality.
\n
Improved usability for large search results.
\n
Improved runtime output readability.
\n
\n
Compatibility
\n
Vix.cpp v2.1.2 introduces no breaking changes.\nExisting CLI workflows remain compatible.\nThe main difference is improved usability: shell completion can now be generated, search results can be paginated, command suggestions are more accurate, and runtime output behaves more reliably during vix run.
\n
Notes
\n
Vix.cpp v2.1.2 is a developer experience release.\nIt improves how users interact with the CLI, how they navigate search results, how they discover commands, and how they observe running applications.\nThis release continues the work of making Vix feel like a complete C++ development tool, not only a build command.
\n';
+const v2_1_2 = {
+ html
+};
+export {
+ v2_1_2 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.3-8rUhMahW.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.3-8rUhMahW.js
new file mode 100644
index 000000000..80b278d33
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.3-8rUhMahW.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.3
\n
Vix.cpp v2.1.3 is a developer experience and CLI workflow release.\nThis release improves runtime output, introduces task execution through vix.json, adds project utilities, introduces formatting support, adds environment inspection through vix info, supports global updates, improves REPL capabilities, and strengthens generated project workflows.\nThe focus of this release is predictability. Vix output should be clean, runtime logs should be stable, generated projects should align with the build workflow, and developers should have better tools to inspect and manage their environment.
\n
Clean runtime output
\n
The main improvement in Vix.cpp v2.1.3 is cleaner runtime output.\nTerminal clearing and spinner behavior were removed from application execution. This makes vix run output more stable, minimal, and production-friendly.\nRuntime output should not hide what the application prints. It should not rewrite the terminal in ways that make logs harder to copy, inspect, or compare.\nVix.cpp v2.1.3 moves the runtime toward predictable output that works better in terminals, CI logs, demos, and production-like workflows.
\n
Task system and project utilities
\n
This release introduces task execution through vix.json.\nThe new task system gives projects a structured way to define reusable commands and workflows inside the project configuration.\nThis is an important CLI foundation because real projects usually need more than build and run. They need repeatable tasks for formatting, checks, scripts, setup, local workflows, and project-specific commands.\nVix.cpp v2.1.3 also adds new project utilities to make project management smoother from the CLI.
\n
Formatting command
\n
Vix.cpp v2.1.3 adds a new formatting command.\nThe vix fmt command gives projects a direct workflow for improving code consistency.\nThis is part of the broader Vix direction: common development tasks should be available from the same CLI that already handles project creation, build, run, checks, and environment inspection.
\n
Info command
\n
This release adds the vix info command.\nThe command displays environment details, cache statistics, and disk usage.\nThis gives developers better visibility into the local Vix environment. That matters because runtime tools often depend on caches, build directories, installed binaries, environment variables, and platform-specific paths.\nA good CLI should make that state inspectable.
\n
Global update support
\n
Vix.cpp v2.1.3 adds global update support through the -g flag.\nThis allows users to update Vix globally when needed.\nFor a developer tool, update behavior must be explicit and understandable. Adding a global update mode creates a clearer path for managing the installed CLI outside a single project.
\n
REPL improvements
\n
The REPL receives improved support for JSON access, array indexing, and typed literals.\nThis makes runtime interaction more useful and expressive.\nThe release also adds REPL documentation through:
\n
docs/vix_repl.md
This gives users a better reference for understanding REPL behavior and runtime interactions.
\n
Project scaffolding improvements
\n
Generated projects now better align with the Vix build workflow.\nThis is important because scaffolding is often the first experience a developer has with a tool. A generated project should teach the correct workflow by default.\nVix.cpp v2.1.3 improves project generation so the created structure feels closer to how Vix expects projects to build, run, and evolve.
\n
Template and module fixes
\n
This release guards template examples, tests, and benchmarks subdirectories more carefully.\nThe time module also excludes benchmarks from library sources, preventing duplicate main symbols during compilation.\nThese fixes improve build correctness and prevent example or benchmark code from accidentally leaking into library builds.
\n
Runtime log formatting
\n
Vix.cpp v2.1.3 improves runtime log formatting by adding proper spacing between labels and values.\nThis is a small change, but it improves readability. CLI output should be clear and consistent, especially when developers use it repeatedly during debugging.
\n
Highlights
\n
\n
Removed terminal clearing from runtime output.
\n
Removed spinner behavior from application execution.
\n
Added task execution through vix.json.
\n
Added project utilities.
\n
Added the vix fmt command.
\n
Added the vix info command.
\n
Added environment details, cache statistics, and disk usage reporting.
\n
Added global update support through -g.
\n
Improved runtime output readability.
\n
Improved REPL support for JSON access.
\n
Improved REPL support for array indexing.
\n
Improved REPL support for typed literals.
\n
Improved project scaffolding.
\n
Guarded template examples, tests, and benchmark subdirectories.
\n
Fixed runtime log formatting spacing.
\n
Excluded time benchmarks from library sources.
\n
Added REPL documentation in docs/vix_repl.md.
\n
\n
Compatibility
\n
Vix.cpp v2.1.3 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is developer experience: runtime output is cleaner, CLI workflows are broader, and generated projects better match the Vix build model.\nApplications should continue to run normally while producing more predictable terminal output.
\n
Notes
\n
Vix.cpp v2.1.3 improves the daily workflow around Vix.\nIt makes runtime output cleaner, adds task execution, introduces formatting and environment inspection commands, improves global update behavior, strengthens the REPL, and makes scaffolding more consistent.\nThis release continues the direction of turning Vix into a complete C++ development workflow, not only a build and run command.
\n';
+const v2_1_3 = {
+ html
+};
+export {
+ v2_1_3 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.4-DQJS7GWq.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.4-DQJS7GWq.js
new file mode 100644
index 000000000..390cef399
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.4-DQJS7GWq.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.4
\n
Vix.cpp v2.1.4 is a code quality and build consistency release.\nThis release focuses on making the codebase warning-free under strict compiler flags, improving runtime safety, cleaning CLI internals, standardizing CMake usage across modules, and isolating third-party warnings more effectively.\nThe focus of this release is maintainability. A runtime ecosystem cannot stay reliable if warnings, unsafe patterns, inconsistent CMake usage, and platform-specific code paths accumulate over time.
\n
Warning-free builds
\n
The main improvement in Vix.cpp v2.1.4 is the cleanup required to reach a warning-free build across CLI, core, and modules.\nThe codebase was cleaned under strict compiler flags such as:
\n
-Wall -Wextra -Wconversion
This matters because warnings in a C++ runtime are not just cosmetic. They can hide real bugs, unsafe conversions, unused execution paths, platform assumptions, and future portability issues.\nVix.cpp v2.1.4 reduces that risk by treating warning cleanup as part of runtime quality.
\n
Safer runtime code
\n
This release replaces several unsafe or noisy implementation patterns with cleaner modern C++ constructs.\nThat includes reducing unsafe snprintf usage, removing redundant moves, cleaning implicit conversions, and improving request/session construction paths.\nThe goal is not only to silence warnings. The goal is to make the runtime code easier to reason about and safer under stricter compiler analysis.
\n
Core and session fixes
\n
The core module receives fixes around const char[] versus char* handling.\nThis prevents template issues and removes warning noise in console-related code.\nThe session layer also removes redundant std::move usage during request construction. This makes the code cleaner and avoids misleading ownership signals.\nSmall fixes like these matter in a runtime because they improve correctness and readability at the same time.
\n
CLI cleanup
\n
Vix.cpp v2.1.4 cleans several CLI internals.\nUnused variables, functions, and parameters were removed across commands and the REPL. Platform-specific helpers are now better guarded so Windows-only utilities do not affect other targets.\nThe run command also removes unused runtime variables, and the REPL receives improved argument parsing and validation.\nThis makes the CLI easier to maintain and reduces the chance that unused or platform-specific code creates warnings in unrelated builds.
\n
CMake consistency
\n
This release improves build system consistency across modules.\nCMake configuration now uses more consistent target_link_libraries patterns, avoiding mixed signature usage and reducing linking inconsistencies.\nFor a modular C++ project, CMake consistency is part of the architecture. If each module expresses dependencies differently, package exports, standalone builds, and umbrella builds become harder to maintain.\nVix.cpp v2.1.4 cleans that foundation.
\n
Third-party warning isolation
\n
External warnings from dependencies such as Asio, spdlog, and fmt are now better isolated using SYSTEM includes.\nThis keeps strict warning builds focused on Vix code instead of surfacing warning noise from third-party headers.\nThat distinction is important. Vix should remain strict about its own code, while not letting external dependency warnings break the developer experience.
\n
CLI documentation
\n
The CLI command reference was updated.\nThe README now reflects the complete vix -h command list, giving users a more accurate view of available commands.\nDocumentation consistency matters because CLI behavior and documentation should evolve together.
\n
Developer experience
\n
Vix.cpp v2.1.4 improves the development environment by making builds cleaner, warnings more meaningful, and module behavior more consistent.\nA warning-free codebase gives contributors a stronger baseline. New warnings become easier to notice because they are not hidden inside existing noise.\nThis directly improves long-term maintainability.
\n
Highlights
\n
\n
Cleaned CLI, core, and modules for warning-free builds.
\n
Improved strict compiler compatibility with -Wall, -Wextra, and -Wconversion.
\n
Standardized CMake configuration across modules.
\n
Improved target_link_libraries consistency.
\n
Isolated third-party warnings using SYSTEM includes.
\n
Improved CLI command handling.
\n
Improved REPL flow and validation.
\n
Replaced unsafe or noisy runtime patterns with safer C++ constructs.
\n
Fixed const char[] versus char* handling in core console code.
\n
Removed redundant std::move usage in session request construction.
\n
Removed unused CLI variables, functions, and parameters.
\n
Guarded platform-specific helpers correctly.
\n
Removed unused runtime variables in vix run.
\n
Fixed CMake linking inconsistencies.
\n
Updated the CLI command reference in the README.
\n
\n
Compatibility
\n
Vix.cpp v2.1.4 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is internal quality: builds should be cleaner, warnings should be reduced, and CMake configuration should be more consistent across modules.
\n
Notes
\n
Vix.cpp v2.1.4 is a maintenance release, but it is strategically important.\nWarning-free builds, strict compiler hygiene, safer runtime patterns, clean CMake boundaries, and accurate CLI documentation all make the project easier to evolve.\nThis release improves the foundation that later runtime, SDK, and packaging work depends on.
\n';
+const v2_1_4 = {
+ html
+};
+export {
+ v2_1_4 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.5-Do3ix5RR.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.5-Do3ix5RR.js
new file mode 100644
index 000000000..4699d264d
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.5-Do3ix5RR.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.5
\n
Vix.cpp v2.1.5 is a release pipeline and cross-compilation stability release.\nThis release fixes the Linux aarch64 build pipeline, improves dependency discovery during cross builds, adds missing dependencies for the utils module, and stabilizes the CI pipeline across Linux, macOS, and Windows.\nThe focus of this release is release reliability. Vix should produce valid artifacts across supported platforms, including native and cross-compiled targets.
\n
Linux aarch64 build pipeline
\n
The main fix in Vix.cpp v2.1.5 is the Linux aarch64 release pipeline.\nThe previous cross-compilation setup did not correctly resolve required system packages such as spdlog and fmt. This could cause configuration failures during release builds and prevent valid Linux aarch64 artifacts from being produced.\nVix.cpp v2.1.5 updates the CMake toolchain configuration so cross builds can resolve the required dependencies more reliably.
\n
Cross-build dependency discovery
\n
This release improves dependency discovery during cross-compilation.\nThe CMake setting:
\n
CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
was updated to allow both target and host package resolution where needed.\nThis matters because cross builds often need to distinguish between packages required for the target environment and tools or metadata required from the host environment. If CMake is too restrictive, dependencies that exist in the build environment may still fail to resolve.\nVix.cpp v2.1.5 makes this path more robust.
\n
Missing utils dependencies
\n
The aarch64 build environment now installs the missing spdlog and fmt dependencies required by the utils module.\nThis prevents configuration failures caused by missing logging and formatting dependencies.\nThe fix also aligns the aarch64 environment more closely with native builds, reducing differences between platform targets.
\n
CI reliability
\n
Vix.cpp v2.1.5 improves release reliability by stabilizing the CI pipeline across supported targets.\nThe affected targets include Linux, macOS, and Windows.\nThis release specifically supersedes v2.1.4, which was affected by a Linux aarch64 CI issue and may not produce valid release artifacts.
\n
Cross-compilation consistency
\n
This release improves consistency between native builds and cross builds.\nThe dependency setup is now better aligned so the aarch64 release path behaves more like the standard platform builds.\nFor a C++ runtime project, this is important because release artifacts must be reproducible and trustworthy across every supported architecture.
\n
Highlights
\n
\n
Fixed the Linux aarch64 build pipeline.
\n
Updated CMake toolchain configuration for cross-compilation.
\n
Improved resolution of spdlog and fmt during cross builds.
\n
Updated CMAKE_FIND_ROOT_PATH_MODE_PACKAGE.
\n
Allowed both target and host package resolution where needed.
\n
Added missing spdlog dependency to the aarch64 build environment.
\n
Added missing fmt dependency to the aarch64 build environment.
\n
Fixed utils module configuration failures in aarch64 builds.
\n
Improved release reliability across Linux, macOS, and Windows.
\n
Improved consistency between native and cross builds.
\n
Superseded the broken v2.1.4 release pipeline.
\n
\n
Compatibility
\n
Vix.cpp v2.1.5 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is release stability: Linux aarch64 artifacts should now be produced through a working pipeline with the required dependencies available during configuration.
\n
Notes
\n
Vix.cpp v2.1.4 was affected by a Linux aarch64 CI issue and may not produce valid release artifacts.\nVix.cpp v2.1.5 supersedes v2.1.4 with a working release pipeline.\nThis release is important because architecture support is only meaningful when release artifacts are built, validated, and distributed reliably.
\n';
+const v2_1_5 = {
+ html
+};
+export {
+ v2_1_5 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.6-CMR-9ige.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.6-CMR-9ige.js
new file mode 100644
index 000000000..062e469c2
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.6-CMR-9ige.js
@@ -0,0 +1,8 @@
+const html = "
Vix.cpp v2.1.6
\n
Vix.cpp v2.1.6 focuses on release stability across Linux targets.
\n
The previous releases exposed an important infrastructure problem: the native Linux x86_64 build and the aarch64 cross-compilation build were not using a fully aligned dependency environment. For a C++ runtime, this kind of issue is critical because release artifacts must be reproducible, portable, and predictable before users can trust the SDK in real projects.
\n
Release focus
\n
This version restores the missing system packages required by the Linux x86_64 release pipeline and fixes the aarch64 cross-compilation environment. The work mainly affects dependency resolution, CMake package discovery, and CI consistency.
\n
The affected dependency set includes spdlog, fmt, OpenSSL, zlib, SQLite, and Brotli on native Linux builds, plus missing spdlog and fmt setup for the aarch64 build environment.
\n
Fixes
\n
\n
Restored missing Linux x86_64 release dependencies.
\n
Fixed missing spdlog and fmt dependencies in the aarch64 cross-compilation job.
\n
Improved CMake toolchain behavior for package discovery during cross-compilation.
\n
Stabilized Linux release jobs affected by previous CI configuration issues.
\n
\n
Improvements
\n
\n
Aligned dependency setup between native Linux and aarch64 release builds.
\n
Improved release reliability for Linux artifacts.
\n
Reduced platform-specific CI failures caused by incomplete build environments.
\n
Strengthened the foundation for consistent SDK packaging across supported platforms.
\n
\n
Notes
\n
Vix.cpp v2.1.4 and v2.1.5 exposed release pipeline issues around Linux builds. Vix.cpp v2.1.6 closes that gap and establishes a more stable baseline for Linux, macOS, and Windows release targets.
\n";
+const v2_1_6 = {
+ html
+};
+export {
+ v2_1_6 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.7-DMvjQfJo.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.7-DMvjQfJo.js
new file mode 100644
index 000000000..d9cbb8262
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.7-DMvjQfJo.js
@@ -0,0 +1,8 @@
+const html = "
Vix.cpp v2.1.7
\n
Vix.cpp v2.1.7 is a cross-platform CI stability release.\nThis release fixes the remaining macOS build failures, completes dependency setup across Linux and macOS targets, and improves release reliability across all supported platforms.\nThe focus of this release is build consistency. Vix should compile reliably across Linux, macOS, and Windows without missing system packages or platform-specific dependency gaps.
\n
macOS build fix
\n
The main fix in Vix.cpp v2.1.7 is resolving macOS build failures caused by missing dependencies.\nThe macOS build environment now installs the required spdlog and fmt packages before CMake configuration.\nThis prevents configuration failures caused by missing logging and formatting dependencies.
\n
Cross-platform dependency setup
\n
This release completes the system dependency setup across supported CI targets.\nRequired packages are now installed consistently for:
\n
\n
Linux x86_64
\n
Linux aarch64
\n
macOS
\n
\n
This improves reliability for release builds and reduces the risk that a platform fails only because its CI environment was missing a dependency already available elsewhere.
\n
CI stability
\n
Vix.cpp v2.1.7 improves CI stability across Linux, macOS, and Windows.\nThe dependency installation strategy is now more unified, which makes the build matrix easier to maintain and less fragile.\nFor a C++ runtime project, CI stability is critical. If the build matrix is unreliable, it becomes harder to trust releases, test platform support, or validate changes confidently.
\n
Release reliability
\n
This release eliminates remaining platform-specific issues that affected previous releases.\nVix.cpp v2.1.6 fixed Linux builds, but macOS builds were still incomplete. Vix.cpp v2.1.7 completes that work and makes the release process more dependable across supported platforms.
\n
Highlights
\n
\n
Fixed macOS build failure.
\n
Added missing spdlog dependency to the macOS build environment.
\n
Added missing fmt dependency to the macOS build environment.
\n
Completed cross-platform dependency setup.
\n
Ensured required packages are installed across Linux x86_64, Linux aarch64, and macOS.
\n
Improved CI stability across all supported targets.
Vix.cpp v2.1.7 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is release and CI stability: supported platforms should now have the required dependencies installed before configuration and build steps.
\n
Notes
\n
Vix.cpp v2.1.6 fixed Linux builds, but macOS dependency setup was still incomplete.\nVix.cpp v2.1.7 completes the missing platform work and establishes the first fully stable release path across all supported targets.\nThis release is important because reliable cross-platform CI is the foundation for every later runtime, SDK, and packaging improvement.
\n";
+const v2_1_7 = {
+ html
+};
+export {
+ v2_1_7 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.8-BqcCKMyP.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.8-BqcCKMyP.js
new file mode 100644
index 000000000..1b2c360b9
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.8-BqcCKMyP.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.8
\n
Vix.cpp v2.1.8 is a cross-platform build stability release.\nThis release fixes a macOS build failure caused by usage of an internal spdlog header, improves logging module portability, and finalizes build consistency across Linux, macOS, and Windows.\nThe focus of this release is portability. Vix should rely on stable public APIs from dependencies, not internal headers whose availability may change between versions or package environments.
\n
spdlog compatibility fix
\n
The main fix in Vix.cpp v2.1.8 is replacing usage of:
\n
#include <spdlog/fmt/ostr.h>
with:
\n
#include <fmt/ostream.h>
The previous include relied on an internal spdlog header path. That worked in some environments but failed on macOS with newer spdlog and fmt versions.\nVix.cpp v2.1.8 moves the logging code to the official fmt API, which is a cleaner and more portable integration path.
\n
Logging module portability
\n
This release improves the portability of the logging module by removing reliance on spdlog internal headers.\nThat matters because internal dependency headers are not stable API contracts. They can change depending on package version, platform, package manager, or build configuration.\nBy using the official fmt header instead, Vix makes the logging module easier to build and maintain across environments.
\n
macOS build stability
\n
Vix.cpp v2.1.8 addresses the remaining macOS build issues exposed after the previous CI dependency fixes.\nThe result is a more stable build path for macOS developers and CI environments.\nThis is especially important because macOS package managers and dependency layouts can differ significantly from Linux and Windows setups.
\n
Cross-platform consistency
\n
This release improves overall build consistency across all supported platforms.\nLinux, macOS, and Windows builds now share a more reliable logging dependency path.\nThe goal is simple: the same Vix source tree should build successfully across supported targets without platform-specific surprises caused by dependency internals.
\n
Highlights
\n
\n
Fixed macOS build failure caused by spdlog internal header usage.
\n
Replaced spdlog/fmt/ostr.h with fmt/ostream.h.
\n
Aligned logging code with the official fmt API.
\n
Removed reliance on spdlog internal headers.
\n
Improved logging module portability.
\n
Addressed remaining macOS build issues.
\n
Improved build consistency across Linux, macOS, and Windows.
\n
Finalized cross-platform build stability after CI dependency fixes.
\n
\n
Compatibility
\n
Vix.cpp v2.1.8 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is internal dependency portability: the logging module now uses the official fmt API instead of relying on an internal spdlog header.\nProjects should benefit from more stable builds, especially on macOS environments with newer spdlog and fmt packages.
\n
Notes
\n
Vix.cpp v2.1.7 fixed CI dependency issues but exposed a compatibility issue with spdlog on macOS.\nVix.cpp v2.1.8 resolves that issue and stabilizes the logging dependency path across supported platforms.\nThis release is small, but it is important because dependency portability is part of runtime reliability. A C++ ecosystem must build cleanly across environments before higher-level developer workflows can be trusted.
\n';
+const v2_1_8 = {
+ html
+};
+export {
+ v2_1_8 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.9-CvgpXLk5.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.9-CvgpXLk5.js
new file mode 100644
index 000000000..f8df216d8
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.1.9-CvgpXLk5.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.1.9
\n
Vix.cpp v2.1.9 is a cross-platform build reliability release.\nThis release completes the transition to explicit fmt integration, fixes macOS header resolution issues, improves dependency propagation for logging utilities, removes fragile spdlog detection logic, and simplifies CMake dependency handling across platforms.\nThe focus of this release is predictable dependency configuration. Vix modules should expose the headers and libraries they require without depending on fragile implicit behavior.
\n
fmt header resolution on macOS
\n
The main fix in Vix.cpp v2.1.9 is resolving a fmt header include failure on macOS.\nSome builds could fail when headers such as:
\n
#include <fmt/ostream.h>
were not resolved correctly.\nVix.cpp v2.1.9 fixes this by linking fmt as a direct dependency where it is required.\nThis matters because header availability should not depend on accidental transitive includes or platform-specific package layout.
\n
Logging dependency propagation
\n
This release also corrects dependency propagation for the logging module.\nfmt is now exposed as a PUBLIC dependency where needed, ensuring headers are available to all consumers that include Vix logging-related headers.\nThat is important for installed packages and downstream CMake projects. If a public header requires a dependency, that dependency must be visible to consumers.\nOtherwise, the module may build internally but fail when used from another project.
\n
Simplified spdlog and fmt configuration
\n
Vix.cpp v2.1.9 removes fragile spdlog and fmt detection logic.\nPrevious build configuration included conditional handling around SPDLOG_FMT_EXTERNAL. That made the build harder to reason about and created platform-specific fragility.\nThis release simplifies the model with explicit and predictable linking.\nThe goal is clearer CMake behavior: dependencies should be declared directly instead of inferred through conditional paths.
\n
Cross-platform build reliability
\n
Dependency handling for spdlog and fmt is now more consistent across Linux, macOS, and Windows.\nThis improves CI stability and makes local builds easier to reproduce.\nFor a C++ runtime ecosystem, cross-platform reliability depends heavily on correct dependency propagation. The same code should not require different hidden assumptions on each platform.
\n
CMake clarity
\n
This release improves CMake maintainability by simplifying dependency configuration.\nExplicit dependency links are easier to debug, easier to export, and easier for downstream projects to consume.\nVix.cpp v2.1.9 continues the cleanup started in v2.1.8 by completing the fmt migration at the CMake level.
\n
Highlights
\n
\n
Fixed fmt header include failure on macOS.
\n
Ensured <fmt/ostream.h> resolves correctly.
\n
Linked fmt as a direct dependency where required.
\n
Corrected dependency propagation for the logging module.
\n
Exposed fmt as a PUBLIC dependency for consumers.
\n
Removed fragile spdlog fmt detection logic.
\n
Removed conditional dependency behavior around SPDLOG_FMT_EXTERNAL.
\n
Improved cross-platform build reliability.
\n
Unified spdlog and fmt dependency handling across Linux, macOS, and Windows.
\n
Improved CMake clarity and maintainability.
\n
Simplified dependency configuration with explicit linking.
\n
\n
Compatibility
\n
Vix.cpp v2.1.9 introduces no breaking changes.\nExisting projects remain compatible.\nThe main difference is that projects consuming logging-related headers should now receive the required fmt dependency more reliably.\nmacOS builds should no longer fail because of missing fmt headers such as <fmt/ostream.h>.
\n
Notes
\n
Vix.cpp v2.1.8 introduced the fmt migration but missed proper linkage in CMake.\nVix.cpp v2.1.9 completes that transition and stabilizes dependency handling across supported platforms.\nThis release is important because clean dependency propagation is part of the public API contract of a C++ SDK. If a module exposes headers that require a dependency, the build system must expose that dependency correctly too.
\n';
+const v2_1_9 = {
+ html
+};
+export {
+ v2_1_9 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.2.0-C0-0jJsb.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.2.0-C0-0jJsb.js
new file mode 100644
index 000000000..92615b76c
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.2.0-C0-0jJsb.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.2.0
\n
Vix.cpp v2.2.0 is a dependency management and package resolution release.\nThis release introduces a new manifest, resolver, and lockfile architecture for the Vix CLI. It also adds full semver resolution, transitive dependency installation, backward compatibility for legacy vix.json dependencies, and a new interactive configuration generator through vix make:config.\nThe focus of this release is deterministic dependency management.\nA C++ runtime ecosystem needs more than a build command. It also needs a reliable way to describe dependencies, resolve versions, install packages, and preserve reproducible project state.
\n
Manifest, resolver, and lockfile architecture
\n
Vix.cpp v2.2.0 introduces a new dependency architecture built around three core pieces:
\n
\n
manifest
\n
resolver
\n
lockfile
\n
\n
The manifest describes what the project depends on.\nThe resolver determines the correct dependency graph.\nThe lockfile preserves the resolved state so installations remain deterministic across machines and future runs.\nThis is an important foundation for the Vix package ecosystem because dependency installation should not depend on accidental command order or changing registry state.
\n
Semver resolver
\n
This release adds full semver support across dependency-related commands.\nThe resolver can now select package versions correctly for commands such as:
\n
vix add\nvix install\nvix outdated
Semver support is required for a real package manager because projects need to express compatibility ranges while still getting predictable version selection.\nThe goal is to let developers depend on packages safely without manually pinning every version unless they need exact reproducibility.
\n
Transitive dependency resolution
\n
Vix.cpp v2.2.0 enables transitive dependency resolution.\nDependencies are now resolved recursively and installed correctly.\nThis is a major step for package management because real packages often depend on other packages. A resolver that only installs direct dependencies is not enough for a modular ecosystem.\nWith transitive resolution, Vix can build a more complete dependency graph and prepare projects for larger package structures.
\n
Legacy vix.json compatibility
\n
The resolver also supports legacy vix.json dependencies.\nThis preserves backward compatibility with existing packages while enabling the new resolution model.\nThat balance is important. Vix can improve its dependency system without forcing every existing package to migrate immediately.\nThe new resolver can understand older dependency declarations while still moving the ecosystem toward manifest, lockfile, and semver-based workflows.
\n
Interactive configuration generation
\n
Vix.cpp v2.2.0 adds:
\n
vix make:config
This command generates structured configuration files through interactive prompts.\nThe goal is to make configuration setup easier and less error-prone, especially for developers who are starting a new project or want to generate a clean baseline configuration.\nInstead of manually writing configuration from memory, users can generate it through a guided workflow.
\n
Publish validation
\n
This release improves package publishing safety.\nVix now rejects duplicate versions, validates vix.json before publishing, infers versions from git tags, and restores correct build order during publish workflows.\nThese changes protect the registry from invalid or inconsistent releases.\nThey also help package authors avoid mistakes such as publishing the same version twice, releasing invalid manifests, or building packages in the wrong dependency order.
\n
Version resolution fixes
\n
Vix.cpp v2.2.0 fixes edge cases in dependency version resolution.\nThese fixes improve consistency across dependency commands and make the resolver more trustworthy.\nFor a package ecosystem, small resolver inconsistencies can create large downstream problems. This release strengthens the resolver behavior before the ecosystem grows larger.
\n
Highlights
\n
\n
Added manifest, resolver, and lockfile architecture.
\n
Added deterministic dependency resolution.
\n
Added lockfile support.
\n
Added full semver support across dependency commands.
\n
Added correct version selection for add, install, and outdated.
\n
Added vix make:config.
\n
Added interactive prompts for structured config generation.
\n
Added support for legacy vix.json dependencies.
\n
Added transitive dependency resolution.
\n
Fixed duplicate version publishing.
\n
Added vix.json validation before publish.
\n
Added version inference from git tags.
\n
Restored correct publish build order.
\n
Fixed dependency version resolution edge cases.
\n
\n
Compatibility
\n
Vix.cpp v2.2.0 preserves backward compatibility with legacy vix.json dependency declarations.\nExisting packages can continue using their current dependency metadata while the resolver supports the newer dependency architecture.\nThe new dependency system is additive and prepares the ecosystem for more deterministic package workflows.
\n
Notes
\n
Vix.cpp v2.2.0 is a foundational package management release.\nIt gives the Vix ecosystem the pieces required for serious dependency management: manifests, deterministic resolution, semver, lockfiles, transitive dependencies, publish validation, and interactive configuration generation.\nThis release moves Vix closer to a complete C++ application runtime with package management that is predictable enough for real projects.
\n';
+const v2_2_0 = {
+ html
+};
+export {
+ v2_2_0 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.3.0-Bucpbk1f.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.3.0-Bucpbk1f.js
new file mode 100644
index 000000000..af2d5ee8c
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.3.0-Bucpbk1f.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.3.0
\n
Vix.cpp v2.3.0 is a major vix run workflow release.
\n
This release introduces ultra-fast direct C++ execution for single-file programs, smart CMake fallback for scripts that require more complex build support, local script cache support, SQLite and MySQL flags in run/build workflows, better executable detection, and a cleaner execution pipeline.
\n
The focus of this release is speed without losing correctness.\nSimple C++ files should run quickly. More complex files should still fall back to the full CMake path when needed.
\n
Ultra-fast direct C++ execution
\n
Vix.cpp v2.3.0 introduces a new direct execution mode for single C++ files.\nThis mode compiles and runs simple C++ files without going through a full CMake configuration step.\nThat matters because single-file C++ development should feel lightweight. When a developer wants to test a small program, example, algorithm, experiment, or utility, the runtime should not force the full project build path unless it is actually needed.\nThe goal is not to replace CMake.\nThe goal is to avoid using CMake when the input is simple enough to compile directly.
\n
Smart CMake fallback
\n
Direct execution is useful only if it remains safe.\nVix.cpp v2.3.0 adds smart CMake fallback so vix run can automatically switch back to the CMake path when the script requires complex dependencies, project structure, or runtime support that direct compilation cannot safely handle.\nThis gives Vix two execution paths:
\n
\n
direct execution for simple single-file programs
\n
CMake fallback for complex Vix scripts and project-aware builds
\n
\n
This design keeps the fast path fast while preserving the correctness of the native C++ build system.
\n
Script cache improvements
\n
This release improves caching for script builds.\nScript builds are now cached globally and keyed by absolute file path for better reuse across repeated executions.\nVix.cpp v2.3.0 also adds:
\n
--local-cache
for script mode in vix run and vix check.
\n
Local cache support gives developers more control over where script build artifacts are stored and helps align repeated script execution with the broader Vix cache behavior.\nThe result is faster repeated runs with fewer unnecessary rebuilds.
\n
Database flags in run and build workflows
\n
Vix.cpp v2.3.0 adds SQLite and MySQL flags directly to vix run and vix build.\nThis improves the developer experience for small database-backed programs and examples.\nInstead of manually wiring database dependencies for quick experiments, developers can use Vix flags to express that the program needs SQLite or MySQL support.\nThis is especially useful for examples, prototypes, and single-file programs that need to quickly test database logic.
\n
Better executable detection
\n
This release improves executable detection in vix run.\nInstead of assuming the executable name from the project directory, Vix now resolves executables from actual build directories such as bin/ and scanned targets.\nThis makes project execution more reliable.\nA C++ project does not always produce a binary with the same name as the folder. The runtime should inspect the build output instead of guessing.
\n
Reorganized run pipeline
\n
Vix.cpp v2.3.0 reorganizes the internal execution pipeline.\nThe run flow is now cleaner and more robust, with improved process handling and better separation between script execution, project execution, and fallback behavior.\nThis is an important foundation for future runtime work.\nOnce vix run supports direct scripts, CMake fallback, built project binaries, runtime flags, database options, and process handling, the pipeline must be structured clearly. Otherwise every new execution mode becomes harder to maintain.
\n
Configuration improvements
\n
This release also improves the configuration system inside the core module.\nConfiguration structure and handling were cleaned up so runtime and example usage can become more predictable.\nThis supports the broader Vix direction: configuration should be explicit, easy to reason about, and usable from real applications.
\n
Fixes
\n
Vix.cpp v2.3.0 fixes several issues around script detection and build diagnostics.\nVix runtime scripts are now detected correctly in fallback mode, preventing incorrect fallback behavior when running Vix-based scripts.\nCMake error detection was improved to avoid misleading build errors and improve project root handling.\nThe vix_utilsConfig.cmake template was also cleaned up to remove redundant content.
\n
Examples
\n
The examples were updated to better demonstrate the improved run workflow.\nThis includes examples for blocking execution, background execution, and dynamic port usage.\nThese examples help show how the new execution pipeline behaves in practical scenarios.
\n
Highlights
\n
\n
Added ultra-fast direct C++ execution for single-file programs.
\n
Added smart CMake fallback for complex scripts and project-aware builds.
\n
Added --local-cache support for script mode in vix run and vix check.
\n
Added SQLite and MySQL flags in vix run and vix build.
\n
Improved global cache behavior for script builds.
\n
Improved executable detection from real build directories and scanned targets.
\n
Reorganized the vix run execution pipeline.
\n
Improved process handling in the run flow.
\n
Improved core configuration structure and handling.
\n
Fixed Vix runtime script detection in fallback mode.
\n
Improved CMake error detection and project root handling.
\n
Cleaned vix_utilsConfig.cmake.
\n
Updated run examples for blocking, background, and dynamic port usage.
\n
\n
Compatibility
\n
Vix.cpp v2.3.0 introduces no breaking changes.\nCMake remains the correct path for complex projects.\nDirect execution is used for simple single-file programs, while smart fallback keeps project-aware and dependency-heavy cases on the CMake path.\nExisting project workflows should continue to work normally.
\n
Notes
\n
Vix.cpp v2.3.0 is an important step for the vix run experience.\nIt makes simple C++ execution faster, while still respecting the complexity of real C++ projects.\nThe direction is clear: Vix should make the common path fast, but keep the full native build system available whenever correctness requires it.
\n';
+const v2_3_0 = {
+ html
+};
+export {
+ v2_3_0 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.3.1-VxYxMG2R.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.3.1-VxYxMG2R.js
new file mode 100644
index 000000000..1f449675e
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.3.1-VxYxMG2R.js
@@ -0,0 +1,8 @@
+const html = "
Vix.cpp v2.3.1
\n
Vix.cpp v2.3.1 is a patch release focused on packaging and cross-platform stability.\nThis release improves how VixConfig.cmake resolves OpenSSL for consumer projects, especially on macOS environments where OpenSSL is installed through Homebrew and may not be available on the default CMake search paths.
\n
OpenSSL package resolution
\n
The main fix in this release is better OpenSSL resolution in VixConfig.cmake.\nConsumer projects should be able to import and use Vix without manually fighting CMake package discovery when OpenSSL is installed in a non-default location.\nThis is especially common on macOS, where Homebrew installs OpenSSL outside the default system paths.\nVix.cpp v2.3.1 improves that behavior so downstream projects can configure more reliably.
\n
Consumer project stability
\n
This release avoids build failures caused by OpenSSL being installed but not discoverable through the default CMake search paths.\nThat matters because package configuration should be reliable for users consuming Vix as an installed SDK.\nA runtime library is not only judged by its internal code. It must also be easy to import, configure, and link correctly from external projects.
\n
Highlights
\n
\n
Improved OpenSSL resolution in VixConfig.cmake.
\n
Improved consumer project compatibility on macOS.
\n
Improved support for Homebrew-based OpenSSL installations.
\n
Avoided build failures when OpenSSL is installed outside default CMake search paths.
\n
Improved installed package stability for downstream Vix users.
\n
\n
Compatibility
\n
Vix.cpp v2.3.1 introduces no breaking changes.
\n
There are no changes to vix run behavior.\nThere are no runtime feature changes in this release.\nExisting projects should continue to work normally, with improved package configuration behavior when OpenSSL is required.
\n
Notes
\n
Vix.cpp v2.3.1 is intentionally small.\nIt focuses on one important packaging problem: making installed Vix projects more reliable for consumers, especially on systems where OpenSSL is not located in a standard CMake search path.\nThis kind of patch release is important for a C++ runtime ecosystem because reliable package discovery is part of the developer experience.
\n";
+const v2_3_1 = {
+ html
+};
+export {
+ v2_3_1 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.4.0-TOAufyhj.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.4.0-TOAufyhj.js
new file mode 100644
index 000000000..d60114873
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.4.0-TOAufyhj.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.4.0
\n
Vix.cpp v2.4.0 is a major ecosystem release.\nThis release expands the modular architecture of Vix.cpp, introduces native static file serving in the core runtime, adds the new vix::tests module, improves environment handling, standardizes umbrella headers, and adds a large set of real-world examples across the ecosystem.\nThe focus of this release is structure. Vix.cpp is becoming more consistent as a modular C++ runtime where core runtime behavior, configuration, testing, filesystem utilities, process tools, logging, and examples follow the same design philosophy.
Static file serving is now part of the core runtime.\nThis means static files no longer require middleware or a separate bootstrap layer. The router can now serve static files through its fallback path before returning a 404 response.\nThe root mount / was also fixed so nested paths such as /index.html, /style.css, and other frontend assets resolve correctly.\nThis change removes the old static handler bridge and the previous middleware dependency for static serving.\nFor real applications, this matters because serving a frontend, documentation UI, dashboard, or static assets should be a core runtime capability, not an external workaround.
\n
Core runtime cleanup
\n
This release removes the deprecated vix/core.h header.\nThe Vix public API continues moving toward consistent modern C++ include paths, especially through umbrella headers such as:
\n
#include <vix/core.hpp>
and the top-level SDK include:
\n
#include <vix.hpp>
Removing legacy headers keeps the public API cleaner and reduces confusion between old and current runtime entry points.
\n
New standalone modules
\n
Vix.cpp v2.4.0 integrates several new modules into the ecosystem:
\n
\n
env
\n
error
\n
fs
\n
io
\n
log
\n
os
\n
path
\n
process
\n
tests
\n
\n
These modules follow the same Vix design direction: minimal dependencies, predictable behavior, production-oriented APIs, and compatibility with both standalone and umbrella builds.\nThis is important for the long-term architecture because Vix should not be a monolithic runtime where every utility lives inside core.\nInstead, each capability should have a clear module boundary.
\n
Umbrella headers
\n
All major modules now expose a single public entry point.\nExamples include:
This gives Vix a cleaner and more predictable public include model.\nDevelopers no longer need to understand deep internal header paths for common usage. Each module has one obvious public entry point.\nThat improves developer experience while keeping internal organization free to evolve.
\n
Native testing module
\n
Vix.cpp v2.4.0 introduces the new vix::tests module.\nThe testing module follows a simple design:
The goal is not to replace every advanced C++ testing framework.\nThe goal is to provide a small native testing layer that fits the Vix ecosystem, works cleanly with examples and modules, and can integrate with CTest when needed.
\n
Environment system
\n
The environment system is significantly expanded in this release.\nVix.cpp v2.4.0 adds .env file support, layered configuration, typed access, and production-oriented configuration patterns.\nThe examples now cover configuration for:
\n
\n
server settings
\n
database settings
\n
logging settings
\n
WebSocket settings
\n
layered environments
\n
\n
This gives Vix projects a clearer configuration story.\nInstead of hardcoding runtime values or relying on outdated JSON configuration files, applications can now use environment-driven configuration patterns closer to production practice.
\n
Database configuration examples
\n
This release improves database integration examples with environment-driven configuration.\nNew examples cover:
\n
\n
MySQL
\n
SQLite
\n
connection pooling
\n
prepared queries
\n
transactions
\n
\n
A full HTTP + database environment showcase is also included.\nThis matters because database configuration is one of the first places where real applications need clean separation between code, local settings, and deployment settings.
\n
Vix.cpp v2.4.0 makes that workflow more visible and easier to copy into real projects.
\n
Static file examples
\n
Static file serving now has dedicated examples.\nThe new examples include:
These examples demonstrate directory mounting with app.static_dir, automatic index.html resolution, cache control support, and safe path handling.\nThis gives developers a direct path for serving static assets from the Vix core runtime.
\n
Expanded examples
\n
Vix.cpp v2.4.0 adds and updates a large set of examples across modules.\nThe examples now cover configuration, environment loading, error handling, filesystem operations, IO utilities, logging, OS helpers, ORM usage, and HTTP + database integration.\nThis is important because examples are part of the public developer experience.\nA module is easier to trust when it has examples that show real usage patterns rather than isolated toy calls.
\n
Modular architecture
\n
This release improves the modular structure of the Vix ecosystem.\nThe architecture is now cleaner in several areas:
\n
\n
clearer module boundaries
\n
standardized CMake packaging
\n
better separation between core and extensions
\n
native static serving inside the core runtime
\n
standalone module usage
\n
umbrella-compatible module usage
\n
\n
This makes the codebase easier to scale.\nVix can continue adding capabilities without forcing everything into core or exposing unstable internal paths to users.
\n
Highlights
\n
\n
Added native App::static_dir.
\n
Added static file serving through router fallback before 404.
\n
Fixed root mount / for nested static paths.
\n
Removed the legacy static handler bridge.
\n
Removed the middleware dependency for static file serving.
\n
Removed deprecated vix/core.h.
\n
Added the env module.
\n
Added the error module.
\n
Added the fs module.
\n
Added the io module.
\n
Added the log module.
\n
Added the os module.
\n
Added the path module.
\n
Added the process module.
\n
Added the tests module.
\n
Added public umbrella headers across the ecosystem.
\n
Added the native vix::tests module.
\n
Added .env file support.
\n
Added layered configuration support.
\n
Added typed environment access.
\n
Added database configuration examples for MySQL and SQLite.
\n
Added connection pooling, prepared query, and transaction examples.
\n
Added static file examples.
\n
Added expanded examples across config, env, error, fs, io, log, os, and ORM.
\n
Standardized .env.example usage.
\n
Improved documentation across core and db.
\n
\n
Compatibility
\n
Vix.cpp v2.4.0 continues the V2 modularization effort.\nStatic files no longer require middleware or bootstrap code.\nProjects using legacy static middleware patterns should migrate to:
\n
app.static_dir(...);
Projects should also review .env usage and update configuration patterns to the expanded environment system where appropriate.\nThe deprecated vix/core.h header has been removed. Projects should use the modern .hpp headers instead.\nFor testing, projects can adopt vix::tests when they want a small native testing layer aligned with the Vix ecosystem.
\n
Notes
\n
Vix.cpp v2.4.0 is a structural release.\nStatic serving is now native to the runtime. Configuration is centered around .env. Modules expose consistent umbrella headers. Testing has a native module. Examples are broader and closer to real application usage.\nThis release moves Vix.cpp further away from being only a runtime library and closer to being a complete modular C++ application ecosystem.
\n';
+const v2_4_0 = {
+ html
+};
+export {
+ v2_4_0 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.0-B0TXSM65.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.0-B0TXSM65.js
new file mode 100644
index 000000000..294382d1c
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.0-B0TXSM65.js
@@ -0,0 +1,8 @@
+const html = "
Vix.cpp v2.5.0
\n
Vix.cpp v2.5.0 is a runtime stability release.
\n
This release focuses on cleaner shutdown behavior, stronger async cleanup, safer HTTP server lifecycle handling, and more reliable WebSocket session writes.
\n
A major part of this work came from debugging real issues inside a large production-style C++ application. The result is a stronger Vix runtime, especially for mixed HTTP + WebSocket applications where shutdown order, active connections, async cancellation, and detached write operations must be handled correctly.
\n
Runtime stability
\n
The main focus of Vix.cpp v2.5.0 is runtime stability.\nThe core runtime now handles App::close() more safely, improves HTTP server stop and join behavior, fixes thread shutdown ordering, and removes temporary debug traces from shutdown paths.\nThis matters because shutdown is one of the hardest parts of a C++ runtime. A server may still have active sessions, pending async operations, worker threads, write queues, browser connections, and internal services running when shutdown begins.\nThe runtime must stop in the right order.\nVix.cpp v2.5.0 strengthens that flow.
\n
HTTP shutdown behavior
\n
The HTTP server receives important lifecycle improvements.\nThis release improves server stop and join behavior, fixes thread shutdown ordering inside HTTPServer, and restores multi-threaded HTTP I/O workers after temporary debugging constraints.\nMulti-threaded HTTP I/O performance is restored while keeping the safer shutdown behavior introduced during bug isolation.\nThe goal is to keep the runtime fast without keeping temporary debugging bottlenecks in the normal execution path.
\n
Async runtime cleanup
\n
The async runtime receives safer shutdown behavior.\nVix.cpp v2.5.0 improves scheduler shutdown, stabilizes the async runtime stop flow, improves asio_net_service lifecycle management, and adds safer stop/join handling for the async network service.\nThis is important because async cleanup must be deterministic. If the scheduler, network service, and worker threads stop in the wrong order, the runtime can expose deadlocks, dangling operations, invalid callbacks, or stuck joins.\nThis release makes the async shutdown path more predictable.
\n
WebSocket lifecycle fixes
\n
The WebSocket runtime receives several important fixes in this release.\nVix.cpp v2.5.0 improves shutdown coordination in mixed HTTP + WebSocket runtimes, stabilizes low-level WebSocket server stop and join behavior, fixes session write flush lifecycle issues, and corrects session lifetime handling during detached async write operations.\nThe write queue handling was also cleaned up, and missing write path pieces were restored.\nThese changes are especially important for applications with repeated browser refreshes, multiple WebSocket clients, active connections during shutdown, and concurrent async writes.
\n
Mixed HTTP + WebSocket reliability
\n
This release significantly improves behavior in real scenarios involving:
\n
\n
repeated browser refreshes
\n
multiple WebSocket clients
\n
server shutdown with active connections
\n
async cancellation during shutdown
\n
thread join ordering
\n
WebSocket write flush safety\nThese are not cosmetic fixes. They target the difficult edge cases that appear when a C++ backend runtime is used in real interactive applications.\nA runtime that supports both HTTP and WebSocket must coordinate connection shutdown, session ownership, pending writes, and worker cleanup as one system.\nVix.cpp v2.5.0 moves that behavior in the right direction.
\n
\n
Benchmark path improvements
\n
Vix.cpp v2.5.0 adds a dedicated /bench fast path for benchmark builds.\nThe HTTP benchmark path was improved under VIX_BENCH_MODE, with benchmark-specific optimizations isolated from the standard HTTP runtime path.\nThis keeps benchmark measurements useful without polluting normal server behavior.\nThe release was benchmarked at approximately 98k requests per second on the /bench route in release benchmark mode.\nThe important part is separation: benchmark-specific paths remain isolated, while the normal runtime keeps its production behavior.
\n
Build and module reliability
\n
This release improves build consistency for modules that depend on async networking headers.\nPublic Asio propagation from vix::async to dependent modules was fixed, and umbrella build consistency was improved for modules using async networking.\nConditional compilation paths for benchmark-only helpers were also cleaned up, and warning noise was reduced in core and platform-specific sources.\nThese changes strengthen the modular build system and reduce accidental breakage across dependent modules.
\n
Process module cleanup
\n
The process module receives platform-specific cleanup.\nVix.cpp v2.5.0 fixes POSIX platform warnings, improves non-Linux helper isolation in process spawning internals, and cleans up noreturn, unused parameter, and unused helper issues.\nThis keeps stricter builds cleaner and makes platform-specific process code easier to maintain.
\n
Highlights
\n
\n
Stabilized App::close() shutdown flow.
\n
Improved HTTP server stop and join behavior.
\n
Fixed thread shutdown ordering in HTTPServer.
\n
Restored multi-threaded HTTP I/O workers.
\n
Improved scheduler shutdown behavior.
\n
Stabilized async runtime stop flow.
\n
Improved asio_net_service lifecycle management.
\n
Added safer stop/join handling for the async network service.
\n
Fixed shutdown issues in mixed HTTP + WebSocket runtimes.
\n
Improved AttachedRuntime shutdown coordination.
\n
Stabilized WebSocket server stop and join behavior.
Fixed session lifetime issues during detached async write operations.
\n
Restored missing WebSocket write path pieces.
\n
Cleaned up WebSocket write queue handling.
\n
Added a dedicated /bench fast path for benchmark builds.
\n
Improved the HTTP benchmark path in VIX_BENCH_MODE.
\n
Fixed public Asio propagation from vix::async to dependent modules.
\n
Improved umbrella build consistency for async networking modules.
\n
Reduced warning noise in core and platform-specific sources.
\n
Fixed POSIX platform warnings in the process module.
\n
\n
Compatibility
\n
Vix.cpp v2.5.0 introduces no breaking changes.\nIf you use Vix for HTTP + WebSocket applications, this release is recommended.\nIt contains important fixes for shutdown stability, session write handling, async runtime cleanup, and mixed HTTP + WebSocket lifecycle behavior.\nExisting applications should continue to work normally while benefiting from safer runtime cleanup and more predictable shutdown behavior.
\n
Notes
\n
Vix.cpp v2.5.0 is a reliability-focused release.\nIt was heavily validated through real debugging sessions on a large C++ codebase with complex concurrency behavior.\nSeveral difficult bugs were tracked down, including shutdown ordering problems, deadlocks, invalid session lifetime handling, async cleanup issues, and WebSocket write lifecycle problems.\nThis release strengthens the Vix runtime where it matters most: under real server pressure, active connections, repeated reloads, concurrent sessions, and shutdown conditions.
\n";
+const v2_5_0 = {
+ html
+};
+export {
+ v2_5_0 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.1-DNxxjnfV.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.1-DNxxjnfV.js
new file mode 100644
index 000000000..6558320c0
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.1-DNxxjnfV.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.5.1
\n
Vix.cpp v2.5.1 is a stability and ecosystem cleanup release.
\n
This release fixes an important HTTP session lifecycle issue, improves stricter compiler builds, removes legacy example configuration, standardizes examples around .env, updates runtime examples to the current Vix architecture, and adds a complete set of production-oriented WebSocket examples.
\n
The focus of this release is consistency. HTTP, WebSocket, configuration, documentation, and examples are now better aligned with the current Vix runtime model.
\n
HTTP session lifecycle fix
\n
The most important fix in Vix.cpp v2.5.1 is in the core HTTP session lifecycle.\nHTTP sessions now close correctly on EOF instead of continuing to loop.\nThis prevents infinite loops when clients close connections and improves the correctness of connection handling inside the core HTTP runtime.\nFor a backend runtime, EOF handling is not a small detail. A server must treat connection shutdown as a normal lifecycle event, not as a condition that keeps the session alive indefinitely.
\n
Cleaner strict builds
\n
Vix.cpp v2.5.1 also improves strict compiler behavior around Asio headers.\nThe async module now suppresses a false-positive -Wnull-dereference warning around Asio includes using diagnostic push/pop boundaries.\nThis keeps strict warning builds cleaner without weakening warning behavior across the rest of the codebase.\nThe goal is precise warning control: suppress known external false positives locally, but keep Vix code strict.
\n
Runtime architecture alignment
\n
This release updates existing examples to use RuntimeExecutor instead of the legacy threadpool API.\nThat change matters because examples should represent the current architecture, not old internal patterns.\nVix examples now better reflect the runtime direction established in the V2 series: a clearer execution model, cleaner lifecycle management, and less reliance on outdated APIs.
\n
Configuration standardization
\n
Vix.cpp v2.5.1 standardizes example configuration around .env.
\n
Legacy config/config.json files were removed across HTTP and WebSocket examples. Examples now use .env.example files instead.\nThis makes configuration simpler, more familiar, and easier to adapt for real backend projects.\nThe release also removes old references to config/config.json, which helps avoid confusion when users copy examples into real applications.
\n
Production-oriented WebSocket examples
\n
Vix.cpp v2.5.1 adds a complete set of real-world WebSocket examples.\nThe new examples include:
They cover minimal WebSocket setup, HTTP and WebSocket integration, room-based messaging, persistent chat with SQLite, long-polling fallback, runtime metrics, native WebSocket clients, and a full realtime dashboard with HTTP, WebSocket, and UI integration.\nThis gives developers a stronger starting point for real applications.
\n
API documentation improvements
\n
Vix.cpp v2.5.1 improves API discoverability in the core and WebSocket documentation.\nThe core README now includes an OpenAPI and /docs section.\nThe WebSocket README was also improved with clearer runtime usage and examples.\nThis release highlights built-in API documentation endpoints:
\n
/docs\n/openapi.json
/docs provides interactive Swagger UI.\n/openapi.json provides the generated OpenAPI specification.\nThe documentation remains offline-first, with no external CDN requirement.
\n
WebSocket cleanup
\n
The WebSocket module receives a small cleanup by removing the unused set_affinity placeholder function.\nThis is a minor internal improvement, but it keeps the codebase cleaner and avoids exposing unused implementation ideas that are not part of the active runtime design.
\n
Highlights
\n
\n
Fixed HTTP sessions closing on EOF instead of looping.
\n
Suppressed a false-positive -Wnull-dereference warning around Asio headers.
\n
Removed the unused WebSocket set_affinity placeholder.
\n
Migrated all examples from config/config.json to .env.
\n
Removed legacy JSON config files across HTTP and WebSocket examples.
\n
Updated examples to use RuntimeExecutor.
\n
Aligned examples with the current Vix runtime architecture.
Improved WebSocket README runtime usage and examples.
\n
Standardized .env.example files across examples.
\n
Emphasized offline-first API documentation without external CDN dependencies.
\n
\n
Compatibility
\n
Vix.cpp v2.5.1 introduces no breaking changes.\nExisting HTTP and WebSocket runtime behavior remains compatible.\nExample configuration moved from legacy config/config.json files to .env, but this affects examples and documentation rather than existing user applications.
\n
Projects using the current runtime architecture should continue to work normally.
\n
Notes
\n
Vix.cpp v2.5.1 is not a feature-heavy release, but it is an important cleanup release.\nIt fixes a critical HTTP lifecycle issue, improves strict compiler behavior, removes outdated example configuration, aligns examples with RuntimeExecutor, and introduces a stronger WebSocket example suite.
\n
This release continues the V2 direction: Vix is evolving from a runtime into a complete backend system where HTTP, WebSocket, API documentation, configuration, examples, and developer tooling are designed to work together.
\n';
+const v2_5_1 = {
+ html
+};
+export {
+ v2_5_1 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.2-dwlpnqkL.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.2-dwlpnqkL.js
new file mode 100644
index 000000000..338ef3299
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.2-dwlpnqkL.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.5.2
\n
Vix.cpp v2.5.2 is a developer experience and runtime execution release.\nThis release introduces a stable options-based vix::print(...) API, a simple vix::input(...) API, modular runtime and template diagnostics, single-file binary export, runtime target execution, direct binary execution, smarter vix run target resolution, and optional HTTPS support in vix::core.\nThe focus of this release is clarity. Vix.cpp improves how developers write small programs, run different target types, diagnose advanced C++ errors, and configure HTTP or HTTPS server execution.
\n
Stable print and input APIs
\n
Vix.cpp v2.5.2 adds a stable options-based print API.\nThe new API supports Python-like print customization through:
\n
vix::print(vix::options{...}, ...);
The existing print API remains compatible.\nThis release also adds a simple interactive input API for console applications:
\n
vix::input(...);
Dedicated examples were added for both print_v2 and input.\nThese APIs matter because Vix is not only a backend runtime. It also aims to make native C++ application development more ergonomic for small programs, scripts, examples, and teaching workflows.
\n
Runtime diagnostics
\n
Vix.cpp v2.5.2 adds modular runtime error rules in the CLI.\nThe new runtime diagnostics cover common C++ execution failures such as joinable thread destruction, data races, deadlocks, mutex misuse, condition variable misuse, future and promise misuse, thread creation failures, detached thread lifetime issues, invalid container access, iterator misuse, dangling std::string_view, and dangling std::span.\nRuntime error prioritization was also improved so specialized concurrency diagnostics are shown before generic uncaught exception messages.\nThis gives Vix a clearer diagnostic pipeline for real C++ runtime failures, especially the kinds of errors that are common in concurrent and systems-level code.
\n
Template and coroutine diagnostics
\n
Vix.cpp v2.5.2 adds modular template error rules for clearer compile-time diagnostics.\nThe release includes dedicated handling for missing typename before dependent types, missing nested types or type aliases, template argument mismatches, substitution failures, requires-expression failures, concept constraint failures, constrained overload failures, lambda capture lifetime issues, coroutine return type errors, missing co_return, invalid awaitable usage, invalid coroutine promise_type, and missing await_ready, await_suspend, or await_resume.\nIt also improves diagnostics for deleting through a base class with a non-virtual destructor, object slicing, invalid override, and invalid downcasts.\nThis is especially important for advanced C++ users because template, concepts, coroutine, and inheritance errors often produce long compiler traces. Vix does not hide the compiler. It adds a focused diagnostic layer that helps developers reach the actual cause faster.
\n
Single-file binary export
\n
Vix.cpp v2.5.2 adds single-file binary export in vix build.\nDevelopers can now produce executables directly from single-file programs using:
\n
vix build main.cpp --bin --out app
Cross-compilation support for single-file builds was also added through:
\n
vix build main.cpp --target <target>
This makes vix build more useful for small utilities, examples, experiments, and distributable single-file C++ programs.\nThe command reuses the script execution engine from vix run, which keeps build and run behavior consistent.
\n
Runtime targets in vix run
\n
Vix.cpp v2.5.2 expands vix run beyond local scripts and projects.\nThe command now supports runtime targets such as:
\n
vix run docker://nginx -p 8080:80
vix run container://nginx -p 8080:80
vix run ssh://user@host
vix run https://example.com
docker://image and container://image execute containers through Docker.\nssh://user@host executes remote commands through SSH.\nhttp:// and https:// targets fetch URLs through curl.\nRuntime arguments after the target are now forwarded directly to the runtime. This removes the need for --run when using runtime targets.\nVix also adds direct binary execution:
\n
vix run ./app
This release introduces smart target resolution so vix run can automatically resolve between scripts, binaries, projects, and runtime targets.
\n
Interactive execution improvements
\n
Vix.cpp v2.5.2 improves interactive passthrough in vix run.\nConsole applications now forward stdin correctly and display runtime prompts immediately without delayed buffering.\nPTY behavior was also improved by disabling local echo for forwarded runtime input.\nThis fixes issues where interactive C++ programs could behave differently under Vix compared to direct terminal execution.\nFor a runtime-focused CLI, stdin, prompts, and interactive applications must behave predictably. This release makes that path much more reliable.
\n
Optional HTTPS support
\n
Vix.cpp v2.5.2 adds optional HTTPS support in vix::core.\nTLS can be enabled from configuration using:
The HTTP session layer now runs over a generic transport abstraction.\nPlain HTTP sessions use PlainTransport.\nHTTPS sessions use TlsTransport.\nThe release adds TlsConfig, TlsSession, and TlsTransport, and updates HTTPServer to start plain HTTP or HTTPS sessions depending on TLS configuration.\nThe server ready banner now displays HTTPS: when TLS is enabled.\nThe recommended production model remains clear: run the Vix HTTP core behind a TLS-terminating reverse proxy such as Nginx, Caddy, or Traefik. Built-in HTTPS is intended for local development, internal tools, and simple self-hosted deployments.
\n
Transport abstraction
\n
The new transport boundary separates the HTTP parser and session layer from the underlying connection type.\nThis is important because a server session should not be permanently tied to a plain TCP stream.\nBy introducing PlainTransport and TlsTransport, Vix creates a cleaner foundation for connection handling while preserving the existing plain HTTP path.\nThe release also adds native TCP socket handle access in vix::async::net::tcp_stream, which helps transport adapters integrate with lower-level socket behavior.
\n
Script detection and execution pipeline
\n
Vix.cpp v2.5.2 generalizes Vix include detection in the script pipeline.\nAny include matching:
\n
#include <vix/...>
or:
\n
#include "vix/..."
is now recognized automatically.\nAny usage of the vix:: namespace is also detected as Vix runtime usage.\nThis removes the need to maintain a hardcoded list of Vix modules in the script probe. New modules can now be detected without updating the probe manually.\nThe script execution pipeline was also improved so lightweight headers such as vix::print and vix::input no longer force unnecessary CMake fallback.
\n
Highlights
\n
\n
Added a stable options-based vix::print(...) API.
\n
Added vix::print(vix::options{...}, ...) for Python-like print customization.
\n
Added a simple interactive vix::input(...) API.
\n
Added modular runtime error rules in the CLI.
\n
Added diagnostics for concurrency errors, invalid container access, iterator misuse, dangling std::string_view, and dangling std::span.
\n
Added modular template error rules.
\n
Added diagnostics for concepts, constrained overloads, coroutine protocol failures, slicing, invalid overrides, and downcasts.
\n
Added single-file binary export in vix build.
\n
Added --bin and --out for direct executable output.
\n
Added cross-compilation support for single-file builds through --target.
\n
Added runtime target support in vix run.
\n
Added Docker, container, SSH, HTTP, and HTTPS runtime targets.
\n
Added automatic runtime argument forwarding after the target.
\n
Added direct binary execution through vix run ./app.
\n
Added smart target resolution in vix run.
\n
Added optional HTTPS support in vix::core.
\n
Added TlsConfig, TlsSession, and TlsTransport.
\n
Added App::run(const vix::config::Config&) and App::listen(const vix::config::Config&, ...).
\n
Added native TCP socket handle access in vix::async::net::tcp_stream.
\n
\n
Compatibility
\n
Vix.cpp v2.5.2 introduces no breaking changes.\nThe existing print API remains compatible.\nExisting nlohmann::json and Simple.hpp response helpers remain supported while core JSON handling continues to move through vix::json::Json.\nBuilt-in HTTPS support is optional.\nWhen vix::core is built without OpenSSL support, Vix keeps graceful fallback behavior.\nThe recommended production deployment model remains a TLS-terminating reverse proxy in front of the Vix HTTP core.
\n
Notes
\n
Vix.cpp v2.5.2 strengthens both ends of the developer workflow.\nAt the small-program level, it improves print, input, single-file builds, binary export, direct execution, runtime target resolution, and interactive terminal behavior.\nAt the systems level, it improves concurrency diagnostics, template diagnostics, coroutine diagnostics, transport abstraction, and optional HTTPS support.\nThis release makes Vix.cpp more practical as a daily C++ runtime tool while continuing to reinforce its native systems foundation.
\n';
+const v2_5_2 = {
+ html
+};
+export {
+ v2_5_2 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.3-CSmrnrfk.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.3-CSmrnrfk.js
new file mode 100644
index 000000000..3981b47ef
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.3-CSmrnrfk.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.5.3
\n
Vix.cpp v2.5.3 is a major workflow and diagnostics release.\nThis release introduces vix replay, opt-in execution recording, stronger runtime diagnostics, a new incremental build graph foundation, cleaner test and check output, and a dedicated development session engine for vix dev.\nThe focus of this release is observability. Vix.cpp is not only improving how projects build and run. It is also improving how failures are captured, explained, replayed, and debugged.
\n
Execution replay
\n
Vix.cpp v2.5.3 introduces the new vix replay command group.
\n
The goal of replay is to make previous Vix executions inspectable and reproducible. A recorded run stores execution metadata and logs locally under .vix/runs/.
Replay support works for both project runs and single-file script runs.\nRecording is now explicit. Normal vix run executions no longer create replay data automatically. Users must opt in with:
\n
vix run main.cpp --replay
or:
\n
vix run --replay
This keeps normal runs clean while still giving developers a precise tool when they need to inspect or reproduce an execution.
\n
Runtime diagnostics
\n
Vix.cpp v2.5.3 significantly improves runtime error diagnostics.\nThe release adds shared runtime location helpers for extracting file:line:column locations and printing runtime code frames. It also adds source-based fallback hints when logs do not provide an exact user frame.\nThis improves diagnostics for sanitizer and non-sanitizer crashes, including double free, iterator invalidation, segmentation faults, aborts, out-of-range errors, mutex errors, condition variable failures, thread errors, span issues, and std::string_view misuse.\nThe runtime error pipeline now avoids printing raw crash logs before friendly Vix diagnostics.\nThat matters because raw allocator or sanitizer output is useful, but it should not be the first thing most developers see. Vix now tries to present a focused diagnostic first, with a location, a code frame, and one useful hint.
\n
Sanitizer workflow
\n
This release improves sanitizer-driven script execution.\nThreadSanitizer support is now available through:
\n
vix run main.cpp --tsan
Runtime diagnostics for script sanitizer runs are also more precise. For example, vix run file.cpp --san and CMake fallback script runs can now show code frames for crashes such as double free.\nWhen sanitizer logs do not provide a clean user location, Vix attempts to point to suspicious source lines such as delete, delete[], or free().\nThis makes sanitizer output more useful without forcing users to manually scan long raw logs.
\n
Incremental build graph foundation
\n
Vix.cpp v2.5.3 adds a new incremental build graph foundation for vix build.\nThis foundation includes build nodes, build tasks, dependency file parsing, object cache metadata, build graph persistence, and a parallel build scheduler.\nThe build graph can import real build information from:
\n
compile_commands.json\nbuild.ninja
compile_commands.json gives Vix access to real compile commands generated by CMake/Ninja.\nbuild.ninja gives Vix visibility into archive, link, copy, install, and utility edges.\nThis is an important architectural step because Vix build intelligence should be based on the real native build graph, not guessed project structure.\nThe target-aware graph executor is still guarded and experimental. CMake/Ninja remains the stable execution path, and graph execution is protected behind:
\n
VIX_GRAPH_EXECUTOR
This keeps the release safe while preparing Vix for deeper no-op, incremental, and target-aware build decisions.
\n
Build diagnostics
\n
Vix.cpp v2.5.3 improves the default vix build experience.\nBuild output is now cleaner, and detailed internal information such as graph state, artifact cache metadata, project paths, and CMake variables is hidden unless debug logging is enabled.\nThe build command also receives a unified diagnostic style for CMake, compiler, linker, sanitizer, runtime, and template-related errors.\nThe default build path was also improved to focus on the main project target instead of always rebuilding the full all target. When developers need the full CMake behavior, they can still request it explicitly:
\n
vix build --build-target all
This improves no-op and focused rebuild performance while keeping the full build available.
\n
Compiler and template diagnostics
\n
Vix.cpp v2.5.3 improves compile-time error rules with shorter messages, focused hints, code frames, and consistent at: output.\nTemplate diagnostics also receive important improvements.\nThe release adds cleaner diagnostics for concepts, coroutine awaiters, invalid overrides, object slicing, downcasts, and template substitution failures.\nThis matters because advanced C++ errors are often technically correct but difficult to read. Vix does not replace the compiler. It adds a higher-level diagnostic layer that helps users find the relevant part of the error faster.
\n
Test workflow
\n
Vix.cpp v2.5.3 improves vix tests with Vix-native output styling.\nThe test command now has a cleaner header, progress line, success summary, and failure diagnostics. It also extracts failed test names and useful error messages instead of dumping raw runner output by default.
vix tests --raw keeps raw internal test runner output available when needed.\nFiltered test execution makes it easier to run one test or a subset of tests while keeping the command aligned with familiar CTest-style workflows.
\n
Check workflow
\n
Vix.cpp v2.5.3 improves vix check.\nThe command now uses cleaner Vix-native output with progress lines, timing summaries, and reduced default noise.\nFor project mode, sanitizer checks now validate the sanitizer build by default without forcing runtime execution. Runtime validation remains explicit through:
\n
vix check --san --run
Script mode also receives cleaner output for:
\n
vix check file.cpp
and:
\n
vix check file.cpp --san
Successful CMake and Ninja logs no longer leak into normal output during checks.
\n
Development session engine
\n
Vix.cpp v2.5.3 adds a dedicated vix dev session engine.\nThe new development flow includes target-aware rebuild orchestration and a DevFileIndex for faster file watching using filtered file indexing, modification time, and file size comparisons.\nThe dev watcher now ignores build folders, .git, .vix, docs, generated output, and unrelated files.\nDev rebuild output now uses real Ninja progress instead of a fake spinner animation. Terminal output is cleared before application restarts, which prevents stale application output from mixing with rebuild output.\nThe result is a cleaner and more reliable development loop.
\n
Dedicated threadpool and kv modules
\n
Vix.cpp v2.5.3 moves the thread pool implementation out of core and into the dedicated threadpool module.\nIt also adds kv as a dedicated Vix module for durable local-first key-value storage.\nThis improves module boundaries and prepares the runtime for cleaner dependency ownership. Core should not own every runtime facility directly. Moving threadpool and kv into standalone modules makes the architecture easier to maintain and package.
\n
Highlights
\n
\n
Added vix replay for recording, inspecting, listing, cleaning, and replaying previous executions.
\n
Added replay support for project runs and single-file script runs.
\n
Added local replay storage under .vix/runs/.
\n
Added vix replay last, vix replay failed, vix replay show, vix replay list, and vix replay clean.
\n
Added opt-in replay recording through vix run --replay.
\n
Added opt-in OpenAPI/docs mode through vix run --docs.
\n
Added --tsan support for ThreadSanitizer script runs.
\n
Added shared runtime error location helpers and runtime code frames.
\n
Improved sanitizer and non-sanitizer crash diagnostics.
\n
Added the incremental build graph foundation for vix build.
\n
Added compile database import from compile_commands.json.
\n
Added Ninja build edge import from build.ninja.
\n
Added a guarded target-aware graph executor.
\n
Added BuildStyle for consistent build output and diagnostics.
\n
Added Vix-native output styling for vix tests.
\n
Added vix tests --raw.
\n
Added filtered test execution through vix tests --test and vix tests -R.
\n
Added Vix-native output styling for vix check.
\n
Added a dedicated vix dev session engine.
\n
Added DevFileIndex for faster dev-mode file watching.
\n
Added threadpool as a dedicated Vix module.
\n
Added kv as a dedicated Vix module for durable local-first key-value storage.
\n
\n
Compatibility
\n
Vix.cpp v2.5.3 introduces no breaking changes.\nReplay recording is now opt-in. Normal vix run executions no longer create .vix/runs/ unless --replay is passed.\nOpenAPI/docs mode is now opt-in. Documentation generation for vix run is disabled by default unless --docs is passed.\nCMake/Ninja remains the stable default build execution path.\nThe experimental graph executor is guarded behind:
\n
VIX_GRAPH_EXECUTOR
The full CMake all build remains available through:
\n
vix build --build-target all
Notes
\n
Vix.cpp v2.5.3 is an important step toward a more observable C++ runtime workflow.\nThe release improves how Vix records executions, explains runtime crashes, formats compiler and template errors, manages test output, checks projects, watches files, and prepares future incremental builds.\nThe deeper direction is clear: Vix is becoming a C++ development environment where build, run, test, check, dev, diagnostics, and replay are part of one coherent workflow.
\n';
+const v2_5_3 = {
+ html
+};
+export {
+ v2_5_3 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.5-5LAIuhxk.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.5-5LAIuhxk.js
new file mode 100644
index 000000000..b279d4d15
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.5-5LAIuhxk.js
@@ -0,0 +1,8 @@
+const html = "
Vix.cpp v2.5.5
\n
Vix.cpp v2.5.5 is a reliability release for vix run, installed registry dependencies, package exports, and the first experimental vix.app workflow.\nThe most important fix is that vix run now links installed registry dependencies correctly, including compiled modules such as kv. This makes script and application execution more reliable when projects depend on modules installed through the Vix registry.
\n
Registry dependency linking
\n
Before this release, some scripts using installed compiled modules could fail because the runtime build path did not link registry dependencies consistently.\nVix.cpp v2.5.5 fixes this behavior for vix run.
\n
This is especially important for modules that are not header-only. A C++ runtime workflow cannot only resolve include paths; it must also correctly link compiled libraries.
\n
Package export cleanup
\n
This release also fixes package export cleanup to avoid duplicate CMake targets in VixTargets.\nThat matters for installed SDK usage because duplicate exported targets can break downstream CMake consumers or make package configuration harder to reason about.\nThe release also improves installed module consistency for threadpool and kv.
\n
Experimental vix.app support
\n
Vix.cpp v2.5.5 introduces the first experimental version of vix.app.\nThe goal of vix.app is to let simple C++ applications build and run without requiring users to write a visible CMakeLists.txt.\nInternally, Vix generates the required CMake project and continues to use the native CMake/Ninja toolchain. This keeps the workflow compatible with real C++ build systems while reducing the amount of visible configuration needed for small applications.\nIn this release, vix.app is still experimental and only used when no CMakeLists.txt is present.
\n
Highlights
\n
\n
Fixed vix run auto-linking for installed registry dependencies.
\n
Fixed script builds using compiled modules such as kv.
\n
Fixed duplicate CMake target exports in VixTargets.
\n
Fixed installed module consistency for threadpool and kv.
\n
Added threadpool examples for validating script and module usage.
\n
Added experimental vix.app support.
\n
Added generated CMake project support for vix.app based builds and runs.
\n
Added experimental documentation for the current vix.app design.
\n
Added shared app project resolution for CMake and vix.app projects.
\n
Cleaned umbrella CMake install and export behavior.
\n
\n
Compatibility
\n
Vix.cpp v2.5.5 introduces no breaking changes.\nExisting CMake projects keep the current build and run behavior.\nvix.app is experimental in this release and is only used when no CMakeLists.txt exists.
\n";
+const v2_5_5 = {
+ html
+};
+export {
+ v2_5_5 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.6-DhmW7WaF.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.6-DhmW7WaF.js
new file mode 100644
index 000000000..72770f36a
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.5.6-DhmW7WaF.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.5.6
\n
Vix.cpp v2.5.6 is a maintenance release focused on improving generated library workflows, CLI diagnostics, and terminal output consistency.\nThis release fixes the next-step guidance generated by vix new --lib, especially for header-only libraries. The generated instructions now better reflect the current build behavior and recommend vix build --build-target all when building generated library scaffolds.\nIt also improves diagnostics when a requested Ninja target does not exist. Instead of exposing raw Ninja output such as ninja: error: unknown target, Vix now reports a clearer and more focused message.
\n
Workflow fixes
\n
The main correction in this release is around generated library projects.\nHeader-only library scaffolds do not always produce a named executable target, so asking users to build a guessed target can lead to confusing errors. Vix.cpp v2.5.6 aligns the generated instructions with the safer CMake target behavior by recommending the generic all target.
\n
This makes the generated project workflow more reliable for both application projects and library projects.
\n
CLI output improvements
\n
Vix.cpp v2.5.6 also improves the formatting of vix new, vix modules init, and vix modules add.\nThe command output now uses cleaner sections for files, targets, and next steps. Extra spacing was removed so the output feels closer to the rest of the Vix CLI style.\nThis is a small release, but it improves an important part of the developer experience: what users see immediately after creating or modifying a project.
\n
Highlights
\n
\n
Fixed vix new --lib next steps for header-only libraries.
\n
Fixed header-only library build guidance by using vix build --build-target all.
\n
Fixed generated library test workflow documentation.
\n
Fixed unknown Ninja target diagnostics.
\n
Fixed extra spacing in vix new and vix modules command output.
\n
Improved vix new help output for application and header-only library workflows.
\n
Improved generated library README instructions.
\n
Improved vix modules init and vix modules add output formatting.
\n
Aligned CLI help text with the current vix build target behavior.
\n
\n
Compatibility
\n
Vix.cpp v2.5.6 introduces no breaking changes.\nExisting application projects keep the same vix build, vix run, and vix dev behavior.\nHeader-only library projects should use:
\n
vix build --build-target all
when building generated library scaffolds.
\n';
+const v2_5_6 = {
+ html
+};
+export {
+ v2_5_6 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.0-C4YAKsO2.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.0-C4YAKsO2.js
new file mode 100644
index 000000000..940602b61
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.0-C4YAKsO2.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.6.0
\n
Vix.cpp v2.6.0 is one of the largest releases in the V2 series.\nThis 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.\nThe focus of this release is not only feature growth. It is about making Vix.cpp more coherent as a runtime-oriented C++ development environment.
\n
Release focus
\n
The main focus of Vix.cpp v2.6.0 is developer workflow integration.
\n
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:
\n
\n
local AI execution through vix::ai::Agent
\n
simplified application builds through vix.app
\n
Vue + Vix full-stack development workflows
\n
safer and smarter build execution
\n
automatic test preparation
\n
async-based development sessions
\n
native game runtime and export foundations
\n
\n
This release makes Vix.cpp feel less like a collection of modules and more like a unified C++ application runtime.
\n
Local-first AI support
\n
Vix.cpp v2.6.0 introduces the new vix::ai_agent module for local-first AI workflows.\nThe public API is exposed through:
\n
#include <vix/ai.hpp>
The main user-facing entry point is vix::ai::Agent.
\n
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.
\n
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.\nThe CLI also gains the new vix agent command group:
\n
vix agent ask\nvix agent analyze\nvix agent scan
These commands establish the first user-facing workflow for AI-assisted project interaction inside the Vix ecosystem.
\n
Official vix.app support
\n
Vix.cpp v2.6.0 makes vix.app an official application manifest path for simple C++ applications.\nThe goal of vix.app is to let developers build and run C++ applications without writing a visible CMakeLists.txt for simple executable projects.\nA generated application can now use:
\n
vix new my_app --app\nvix build\nvix run\nvix dev\nvix 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/.\nThis keeps the build system explicit and compatible with native C++ tooling, while reducing the amount of build-system ceremony required for small projects.
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.
\n
The development workflow is integrated into vix dev.\nThis 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.\nThis is not a replacement for frontend tooling. Instead, Vix coordinates the native backend and the frontend dev server as one development workflow.
\n
Build system improvements
\n
Vix.cpp v2.6.0 significantly improves the build workflow.\nThe 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.\nThe 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.\nThis is the right tradeoff for a C++ runtime tool: optimize when the model is safe, but never pretend to understand more than it does.\nVix.cpp v2.6.0 also adds:
vix build --warnings provides paginated compiler warning exploration.\nvix build --warning-check builds with stronger compiler warning flags automatically.\nvix build --explain explains why files or targets rebuild.\nTogether, these features move vix build closer to a diagnostic tool, not only a build launcher.
\n
vix run and vix dev improvements
\n
vix run now uses the same project execution path as vix build.\nThis 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.\nVix.cpp v2.6.0 also improves how vix run handles process exits. Normal non-zero exits are no longer treated as runtime crashes.\nvix dev receives deeper changes.
\n
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.\nThis makes the development loop more aligned with the rest of the Vix runtime architecture.\nApplications 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.\nThe result is a quieter and more predictable development workflow.
\n
Test workflow improvements
\n
Vix.cpp v2.6.0 improves vix tests.\nProjects with a tests/ directory can now prepare and run tests automatically when possible, even if the test configuration has not been explicitly completed yet.\nThe command also gains cleaner CTest-based listing and per-test status display.\nThis reduces friction for projects that are still evolving, while keeping compatibility with standard CMake/CTest workflows.
\n
The new vix::reply module
\n
The REPL engine has been moved out of the CLI module into the new standalone vix::reply module.\nThis is an internal architectural improvement, but it matters because the REPL engine is now separated from CLI command implementation details.\nvix repl now uses this standalone module.\nThis makes the REPL foundation easier to evolve and reuse without coupling it too tightly to the CLI layer.
\n
Lightweight developer IO helpers
\n
Vix.cpp v2.6.0 moves lightweight developer helper APIs into the new vix::io ownership model.\nThis includes headers and APIs such as:
This change clarifies module boundaries.\nThe 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.
\n
Game runtime foundation
\n
Vix.cpp v2.6.0 introduces the new vix::game module.\nThis 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.\nThe release adds game-aware project generation:
\n
vix new my_game --game\nvix new my_game --template game
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.
\n
SDL and OpenGL game backend
\n
The vix::game module now includes a backend foundation with:
\n
\n
GameRuntime
\n
GameContext
\n
NullWindow
\n
NullRenderer
\n
SDL window backend
\n
SDL renderer backend
\n
SDL input mapping
\n
texture upload
\n
sprite rendering
\n
runtime diagnostics
\n
architecture tests
\n
\n
Vix.cpp v2.6.0 also adds an SDL OpenGL renderer backend.\nThis includes OpenGL context creation through SDL, shader compilation, VAO/VBO/EBO setup, texture upload, sprite rendering, and glDrawElements rendering.\nThe 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.\nThis gives the game module a real executable direction instead of only abstract runtime types.
\n
Game export workflow
\n
Vix.cpp v2.6.0 adds the first vix::game export workflow.
\n
The new export system includes:
\n
\n
GameExportConfig
\n
GameExporter
\n
GameExportManifest
\n
GameExportAsset
\n
GameAssetPipeline
\n
\n
The CLI now supports:
\n
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.\nThe export workflow is additive. It does not change existing vix build, vix run, vix dev, or vix new --game behavior.
\n
CMake and package export improvements
\n
Vix.cpp v2.6.0 improves umbrella CMake integration and package export behavior.\nThe umbrella CMake module order has been improved so dependencies are configured before the modules that consume them.\nVixConfig.cmake has also been improved so umbrella consumers can load exported Vix targets without requiring internal modules such as vix_io as separate packages.\nThe release adds package configuration support for optional game backends:
This makes game backend availability explicit and keeps optional dependencies under control.
\n
CI and standalone module stability
\n
Vix.cpp v2.6.0 improves standalone CI workflows across several modules, including:
\n
\n
CLI
\n
core
\n
reply
\n
websocket
\n
middleware
\n
database
\n
ORM
\n
net
\n
P2P
\n
P2P HTTP
\n
\n
The release also fixes isolated module dependency layouts so each standalone module receives the sibling modules it needs during CI builds.\nModules that depend on core now preload required dependencies such as json, template, and env before configuring core.\nThese changes are important for a modular C++ codebase because umbrella builds can hide dependency mistakes. Standalone CI forces each module boundary to be explicit.
\n
Highlights
\n
\n
Added the new vix::ai_agent module.
\n
\n
Added public AI support through <vix/ai.hpp> and vix::ai::Agent.
Added tiny_adventure, a complete Vix game example.
\n
\n
Added vix game export.
\n
\n
Added exported game manifests and asset metadata.
\n
\n
Improved vix dev by moving session orchestration to the Vix async runtime.
\n
\n
Improved CMake package export for umbrella consumers and optional game backends.
\n
\n
\n
Compatibility
\n
Vix.cpp v2.6.0 does not introduce breaking changes.\nExisting CMake projects continue to use CMakeLists.txt directly.\nvix.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.\nThe AI agent module is optional and can be disabled with:
\n
-DVIX_ENABLE_AGENT=OFF
The game module is also optional and can be disabled with:
\n
-DVIX_ENABLE_GAME=OFF
SDL game backend support can be enabled with:
\n
-DVIX_GAME_ENABLE_SDL=ON
SDL OpenGL renderer backend support can be enabled with:
\n
-DVIX_GAME_ENABLE_SDL_OPENGL=ON
The graph executor can be disabled with:
\n
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.
\n
Notes
\n
Vix.cpp v2.6.0 is a major workflow release.\nIt introduces AI, application manifests, Vue development workflows, stronger build diagnostics, async-powered development sessions, and the first serious game runtime foundation.\nThe most important architectural direction is consistency.\nvix build, vix run, vix dev, vix tests, vix.app, Vue projects, AI commands, and game projects are becoming part of one coherent runtime workflow.\nThat 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.
\n';
+const v2_6_0 = {
+ html
+};
+export {
+ v2_6_0 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.1-BaBB8IBO.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.1-BaBB8IBO.js
new file mode 100644
index 000000000..fbda5a2e4
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.1-BaBB8IBO.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.6.1
\n
Vix.cpp v2.6.1 is a patch release focused on diagnostics, SDK release validation, and post-v2.6.0 stabilization.
\n
Vix.cpp v2.6.0 was a large release. It introduced major workflow and runtime foundations such as AI agent support, official vix.app support, Vue + Vix workflows, target-aware builds, async-powered development sessions, and the first serious game runtime foundation.
\n
v2.6.1 is the follow-up release that hardens that foundation.
\n
The focus is not new surface area.
\n
The focus is making failures clearer, release packages safer, and SDK consumption more trustworthy.
\n
Release focus
\n
The main focus of Vix.cpp v2.6.1 is reliability after a large release.
\n
Large releases often expose problems that only appear when the full SDK is packaged, installed, linked, and used as a consumer would use it.
\n
v2.6.1 improves that part of the release process.
\n
It strengthens:
\n
\n
runtime diagnostic formatting
\n
build diagnostic location selection
\n
test failure output
\n
vix dev failure reporting
\n
SDK package validation
\n
installed header checks
\n
static library checks
\n
CMake package file checks
\n
exported target validation
\n
full SDK consumer linking through vix::vix
\n
\n
The release makes Vix.cpp better at answering one important question:
\n
If something fails, can the developer quickly understand what failed and why?
Clearer runtime diagnostics
\n
Vix.cpp v2.6.1 improves runtime diagnostic formatting for clearer CLI output.
\n
Runtime failures should not feel like raw noise. They should point the developer toward the useful part of the failure.
\n
This release improves diagnostics for bad variant access errors and generic runtime failures.
\n
When runtime logs contain useful information, Vix now extracts that information and presents it more clearly.
\n
The goal is to reduce the distance between the failure and the fix.
\n
Instead of forcing developers to scan long logs manually, Vix tries to show:
\n
what failed\nwhere it failed\nwhy it likely failed\nwhat context matters
vix dev now uses the same diagnostic pipeline
\n
vix dev runtime failures now route through the same diagnostic pipeline used by vix run.
\n
This matters because development mode should not have weaker error reporting than manual run mode.
\n
Before this change, the same runtime problem could be easier to understand through vix run than through vix dev.
\n
v2.6.1 makes the behavior more consistent.
\n
If an application fails while running inside the development session, Vix can now present the failure through the same diagnostic model used elsewhere in the CLI.
\n
This is part of the larger direction of Vix.cpp:
\n
same project\nsame runtime\nsame diagnostics\nsame developer workflow
Less duplicated runtime output
\n
v2.6.1 reduces duplicated runtime log output when a clear diagnostic is already available.
\n
This is important because a diagnostic tool should not make failures harder to read by printing the same information several times.
\n
When Vix can produce a focused diagnostic, the surrounding logs should support that diagnostic, not bury it.
\n
This makes runtime failure output more compact and easier to scan.
These symbols matter because missing exported symbols can break real consumers even when the source repository builds correctly.
\n
The packaged SDK must not only compile internally.
\n
It must link externally.
\n
v2.6.1 improves that external-consumer confidence.
\n
Internal module reference updates
\n
This release also updates internal module references for the v2.6.1 patch release.
\n
This keeps module versioning and internal references aligned after the v2.6.0 release.
\n
Patch releases often include this kind of maintenance work to ensure the repository, modules, and SDK package all agree on the current release state.
\n
Issues discovered after v2.6.0
\n
v2.6.1 fixes issues discovered after the v2.6.0 release.
\n
This is normal after a large release.
\n
v2.6.0 introduced significant new workflows and infrastructure. v2.6.1 follows by tightening the parts where packaging, diagnostics, and real consumer usage needed stronger validation.
\n
The result is a more trustworthy v2.6 line.
\n
Highlights
\n
\n
Updated internal module references for the v2.6.1 patch release.
\n
\n
Improved runtime diagnostic formatting for clearer CLI output.
\n
\n
Improved CLI runtime diagnostics for bad variant access errors.
\n
\n
Added clearer diagnostics for missing runtime resources.
\n
\n
Improved generic runtime failure handling by extracting useful error information from runtime logs.
\n
\n
Routed vix dev runtime failures through the same diagnostic pipeline used by vix run.
\n
\n
Reduced duplicated runtime log output when a clear diagnostic is already available.
\n
\n
Improved build diagnostic location selection to prefer user code over system headers.
\n
\n
Fixed misleading build diagnostics that pointed to standard library headers instead of project files.
\n
\n
Improved test failure output to render CTest assertion failures as clean Vix diagnostics.
\n
\n
Fixed vix tests output for failed C/C++ assertions by showing the failing source location, assertion message, and code frame.
\n
\n
Strengthened the SDK release workflow to validate a complete and faithful Vix SDK package.
\n
\n
Added stricter SDK release checks for installed headers, static libraries, CMake package files, and exported Vix targets.
\n
\n
Improved SDK release validation to ensure vix::vix can be used as the single consumer target for full SDK projects.
\n
\n
Fixed incomplete SDK release validation that allowed missing module libraries to pass CI.
\n
\n
Fixed SDK packaging checks to catch missing WebSocket symbols such as LowLevelServer::run, Session::shutdown_now, and LongPollingManager::push_to.
\n
\n
Fixed SDK consumer validation so packaged releases test real linking through find_package(Vix CONFIG REQUIRED) and target_link_libraries(app PRIVATE vix::vix).
\n
\n
Fixed issues discovered after the v2.6.0 release.
\n
\n
\n
Compatibility
\n
Vix.cpp v2.6.1 does not introduce intentional breaking changes.
\n
Existing v2.6.0 workflows continue to work:
\n
vix build\nvix run\nvix dev\nvix tests
The main changes are improvements to diagnostics and release validation.
v2.6.1 improves release validation so this consumer path is tested more faithfully before an SDK package is accepted.
\n
For CLI users, runtime and test failures should now be easier to understand.
\n
Notes
\n
Vix.cpp v2.6.1 is a small but important patch release.
\n
It improves the experience around failures.
\n
It also makes the SDK release workflow more serious.
\n
That matters because a native C++ application platform cannot only work inside its own repository. It must also work when packaged, installed, found through CMake, linked into a consumer application, and executed through the CLI.
\n
v2.6.1 strengthens that path.
\n
The direction is clear:
\n
better diagnostics\nstronger SDK validation\ncleaner test output\nmore reliable release packages
This release makes the v2.6 series safer after the major v2.6.0 expansion.
\n';
+const v2_6_1 = {
+ html
+};
+export {
+ v2_6_1 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.2-DoUiBLNA.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.2-DoUiBLNA.js
new file mode 100644
index 000000000..81ef91779
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.2-DoUiBLNA.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.6.2
\n
Vix.cpp v2.6.2 is a workflow reliability release.
\n
This release focuses on the parts of Vix.cpp that developers touch every day:
\n
\n
running generic CMake projects
\n
installing dependencies
\n
updating dependencies
\n
listing dependencies
\n
checking outdated packages
\n
publishing packages
\n
preparing registry state
\n
reading build and test diagnostics
\n
using vix.app
\n
installing the Windows SDK
\n
exposing security-sensitive crypto helpers
\n
\n
The goal of v2.6.2 is not to add a large new runtime surface.
\n
The goal is to make the existing Vix.cpp workflow more correct, more predictable, and easier to trust.
\n
Release focus
\n
The main focus of Vix.cpp v2.6.2 is dependency and registry workflow correctness.
\n
Previous releases expanded the Vix platform with vix.app, AI workflows, game tooling, Vue integration, and stronger build and development commands. v2.6.2 focuses on the dependency layer that makes package-based C++ projects practical.
\n
This release improves:
\n
\n
vix install
\n
vix update
\n
vix outdated
\n
vix list
\n
vix publish
\n
registry dependency propagation
\n
generated CMake integration
\n
stale dependency link handling
\n
lockfile metadata updates
\n
package hash refresh behavior
\n
\n
It also improves vix run for generic CMake projects and strengthens diagnostics across build, test, and vix.app workflows.
\n
Crypto security helpers
\n
Vix.cpp v2.6.2 adds two important helpers to the crypto module.
\n
The first addition is constant-time byte comparison helpers.
\n
These are useful for security-sensitive comparisons where normal byte comparison may leak timing information.
\n
The second addition is PBKDF2-HMAC-SHA256 password hashing and verification helpers.
\n
This gives the crypto module a stronger foundation for password-related workflows.
\n
The added capabilities are:
\n
\n
constant-time byte comparison
\n
PBKDF2-HMAC-SHA256 password hashing
\n
PBKDF2-HMAC-SHA256 password verification
\n
\n
This is a small API addition, but it matters because security-sensitive helpers should be easy to use correctly.
\n
vix run for generic CMake projects
\n
vix run receives an important fix for generic CMake projects.
\n
Before this release, vix run could assume that the executable target name matched the folder name. That assumption does not hold for many real CMake projects.
\n
v2.6.2 fixes this by detecting and running the executable produced by the build instead of assuming that the folder name is the target name.
\n
This makes vix run more useful for existing CMake projects that were not created by Vix.
\n
The default vix run output is also kept cleaner during normal execution.
\n
This matters because vix run should be readable during daily development, not noisy by default.
\n
Smarter vix update behavior
\n
vix update receives several important dependency workflow fixes.
\n
The command now updates only dependencies with newer resolved versions instead of reprocessing every dependency in the project.
\n
It also respects the version constraints declared in vix.json instead of always resolving direct dependencies to the latest registry version.
\n
That distinction is important.
\n
A dependency update command should not ignore the project’s declared version policy.
\n
For example, if a project declares a constrained dependency range, vix update should work inside that policy instead of jumping to the latest version unconditionally.
\n
v2.6.2 also improves vix update so it can refresh lockfile metadata and package hashes even when dependency versions do not change.
\n
This allows the lockfile to stay accurate without pretending that a version update happened.
\n
Update summaries are now clearer because they separate:
\n
version changes\nlockfile metadata updates
Already-current dependencies are no longer repeated in the main update summary.
\n
The result is a cleaner and more accurate dependency update experience.
\n
Better vix outdated and vix list output
\n
vix outdated now shows only direct project dependencies from vix.json by default.
\n
The full locked dependency graph is still available with:
\n
vix outdated --all
This improves the default view because most developers first want to know whether the dependencies they directly declared are outdated.
\n
The same model was applied to vix list.
\n
By default, vix list now shows only direct project dependencies from vix.json.
\n
To show transitive locked dependencies, use:
\n
vix list --all
v2.6.2 also adds pagination and JSON output support to vix list.
\n
This makes dependency inspection more useful for both humans and tools.
\n
Cleaner vix install output
\n
vix install output is now more accurate.
\n
It reports only dependencies that were actually installed or relinked instead of counting every dependency from vix.lock as newly installed.
\n
This makes the install summary more honest.
\n
If nothing meaningful changed, the command should not make it look like every dependency was installed again.
\n
Dependency installation messages are also shorter and cleaner.
\n
This improves the developer experience, especially in projects with several dependencies or transitive packages.
\n
Stale dependency link handling
\n
v2.6.2 improves project dependency installation by handling stale or broken .vix/deps links more reliably.
\n
This matters because project-local dependency links can become stale after:
\n
\n
moving a project
\n
deleting dependency stores
\n
switching branches
\n
changing registry versions
\n
cleaning local build state
\n
interrupting previous installs
\n
\n
The install workflow now handles these cases more defensively.
\n
The goal is simple:
\n
if dependency links are stale,\nVix should repair them instead of leaving the project broken.
Transitive registry dependency propagation
\n
This release fixes transitive registry dependency propagation.
\n
Packages such as rix/rix can now expose dependencies such as:
\n
rix/csv\nrix/debug\nrix/auth
without requiring every application to list those dependencies manually.
\n
This is important for the Vix registry model.
\n
A facade package should be able to expose the packages it needs, and applications should not be forced to repeat internal dependency declarations by hand.
\n
This improves the userland package workflow and makes packages such as Rix easier to consume.
\n
Registry workflow tested with Pico
\n
v2.6.2 includes improvements made after testing the registry install, update, and generated CMake integration flow in production with:
\n
pico.vixcpp.com
This matters because registry workflow issues are easiest to find in real package usage.
\n
The release improves the registry dependency workflow based on that production-style validation.
\n
The direction is clear:
\n
registry metadata\n -> resolved dependencies\n -> lockfile\n -> generated CMake integration\n -> working C++ project
The registry workflow must be reliable across all of those steps.
\n
vix publish improvements
\n
vix publish receives several fixes and diagnostic improvements.
\n
The command now gives better diagnostics when a tag exists locally but has not been pushed to origin.
\n
This is important because publishing a package usually depends on Git tags being visible remotely.
\n
v2.6.2 also fixes registry preparation so stale local publish branches and untracked registry entry files are cleaned before checking whether a version already exists.
\n
This reduces false publish failures caused by old local state.
\n
Publishing should fail because of a real package problem, not because the local registry checkout is stale or dirty.
\n
Windows SDK release pipeline
\n
v2.6.2 fixes the Windows SDK release pipeline.
\n
The release now ensures that:
\n
vix-sdk-windows-x86_64.zip
is built, packaged, checksummed, signed, and uploaded to GitHub Releases.
\n
This also fixes the Windows installer failure where install.ps1 attempted to download:
\n
vix-sdk-windows-x86_64.zip
but the asset was missing from the release.
\n
This is an important packaging fix.
\n
A working installer depends on a complete release artifact pipeline.
\n
If the installer expects an asset, the release process must always publish that asset.
\n
Better CMake diagnostics
\n
v2.6.2 improves CMake error parsing.
\n
Multi-line:
\n
message(FATAL_ERROR ...)
diagnostics are now displayed clearly instead of being collapsed into unreadable one-line reasons.
\n
This matters because CMake errors often contain important context across multiple lines.
\n
A build tool should preserve that structure when reporting the failure.
\n
The goal is not to hide CMake.
\n
The goal is to make CMake failures easier to understand.
\n
Better verbose build behavior
\n
vix build -v is now kept readable.
\n
Raw CMake/Ninja output is reserved for:
\n
vix build --cmake-verbose
This gives developers two useful levels of output:
\n
-v\n readable Vix-level verbose output\n\n--cmake-verbose\n raw CMake/Ninja output
That separation matters because normal verbose mode should help developers understand what Vix is doing without flooding the terminal.
\n
When raw build-system logs are needed, they are still available explicitly.
\n
Better vix tests failure diagnostics
\n
vix tests receives improved failure diagnostics.
\n
Test runner output is now summarized with:
\n
\n
clearer failed test names
\n
source locations
\n
focused error messages
\n
compact code frames
\n
\n
This improves the debugging loop.
\n
When tests fail, the developer should quickly see:
\n
which test failed\nwhere it failed\nwhat the focused error was\nwhich code frame matters
This is especially important as Vix.cpp continues to expand module-level tests and CI coverage.
\n
vix.app diagnostics
\n
v2.6.2 improves diagnostics for vix.app projects.
\n
If .vix/vix_deps.cmake is missing, Vix now reports a clearer error.
\n
Resource validation also improves.
\n
Missing resources now fail early with a clear error instead of failing later through a long post-build CMake command.
\n
This is important because vix.app exists to make simple application projects easier.
\n
When something is wrong, the error should point directly to the missing resource or missing generated dependency file.
\n
Build toolchain behavior
\n
This release fixes build toolchain behavior by using absolute system archiver paths.
\n
This improves reliability in environments where tool lookup, PATH configuration, or build generator behavior can otherwise produce inconsistent results.
\n
Small toolchain fixes like this help make builds more reproducible.
\n
Middleware public header improvements
\n
v2.6.2 exposes middleware app integration helpers through the public aggregate header.
\n
It also keeps the middleware aggregate header cache independent.
\n
This improves the public middleware integration surface and keeps include behavior cleaner.
\n
Highlights
\n
\n
Added constant-time byte comparison helpers to the crypto module.
The main behavior changes are correctness and output improvements.
\n
For dependency workflows, default views are now more focused:
\n
vix list\nvix outdated
show direct dependencies by default.
\n
Use:
\n
vix list --all\nvix outdated --all
when you need the full locked dependency graph.
\n
For build output, use:
\n
vix build -v
for readable Vix verbose output.
\n
Use:
\n
vix build --cmake-verbose
when raw CMake/Ninja output is needed.
\n
For generic CMake projects, vix run should now behave better because it detects the built executable instead of assuming the folder name is the executable name.
\n
Notes
\n
Vix.cpp v2.6.2 is a practical release.
\n
It improves the workflows that make Vix usable every day:
Vix.cpp v2.6.2 makes that foundation cleaner and more predictable.
\n';
+const v2_6_2 = {
+ html
+};
+export {
+ v2_6_2 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.3-CsmlOt-t.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.3-CsmlOt-t.js
new file mode 100644
index 000000000..d3e3f345a
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.6.3-CsmlOt-t.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.6.3
\n
Vix.cpp v2.6.3 is a stability and engineering-discipline release.
\n
It does not try to introduce a large new product surface like v2.6.0. Instead, it focuses on making the existing Vix.cpp runtime, CLI, Core module, tests, benchmarks, and CI workflows more reliable.
\n
This release strengthens several areas that matter for a serious C++ application platform:
\n
\n
safer project execution through vix run
\n
better long-running test visibility through vix tests
\n
more deterministic Core shutdown behavior
\n
stronger HTTP session edge-case handling
\n
official Core benchmark baselines
\n
broader sanitizer-ready module testing
\n
better static analysis scope
\n
deterministic threadpool cancellation behavior
\n
improved JSON module coverage
\n
stricter CI without blocking on third-party or irrelevant files
\n
\n
The focus of v2.6.3 is simple:
\n
stabilize the runtime\nmeasure performance\nstrengthen CI\nmake failures easier to trust
Release focus
\n
Vix.cpp v2.6.3 focuses on reliability.
\n
Previous v2.6 releases expanded the platform with AI workflows, vix.app, game tooling, Vue integration, and stronger developer workflows. v2.6.3 takes that foundation and hardens it.
\n
The release improves how Vix behaves when projects are larger, tests are slower, shutdown paths are concurrent, benchmarks are enabled, sanitizer builds are active, and CI needs to distinguish real project problems from false positives.
\n
This is important because Vix.cpp is not only a library. It is becoming a full native application workflow for C++.
\n
That means the project must care about more than APIs.
\n
It must care about:
\n
\n
how applications start
\n
how they stop
\n
how tests run
\n
how failures are diagnosed
\n
how benchmarks are stored
\n
how CI decides what is blocking
\n
how modules behave outside the umbrella build
\n
how release confidence is built
\n
\n
Vix.cpp v2.6.3 is about that confidence.
\n
Registry and publish stability
\n
This release fixes several issues around vix publish and registry state handling.
\n
Publishing now prepares and normalizes the local registry index internally before publishing. That means the publish workflow is less dependent on stale local state.
\n
The local registry state is refreshed more defensively by fetching origin, resetting to origin/main, and cleaning untracked registry entry files before checking existing package versions.
\n
This matters because package publishing should not fail because of an old or dirty local registry checkout.
\n
v2.6.3 also improves diagnostics when a package version already exists in the registry.
\n
The goal is to make registry failures clearer and less surprising.
\n
JSON module fixes and coverage
\n
The JSON module receives an important JPath parsing fix.
\n
Paths after bracket segments now parse correctly, including shapes such as:
\n
users[0].email\n["complex.key"].value
This is a small-looking fix, but it matters because JPath is often used in real data access paths where arrays, object keys, and nested properties are mixed.
\n
The JSON module also receives stronger dedicated CMake targets for examples, tests, and benchmarks.
\n
Documentation was expanded for:
\n
\n
builders
\n
parsing
\n
dumping
\n
safe access
\n
JPath
\n
Simple payloads
\n
tests
\n
benchmarks
\n
useful links
\n
\n
The release also adds benchmark result snapshots for JSON construction, conversion, dumping, parsing, JPath, and Simple payloads.
\n
This improves the JSON module as both a user-facing API and a measurable runtime component.
\n
vix run improvements
\n
vix run receives several important fixes around executable resolution.
\n
CMake projects do not always produce binaries with the same name as the project directory. v2.6.3 fixes executable resolution for those projects.
\n
It also improves diagnostics when a build produces multiple runnable executables.
\n
This makes vix run more reliable in real projects where the build output is not trivial.
\n
The project watch mode also now resolves runnable executables generically instead of assuming the binary name matches the project folder.
\n
That is an important workflow improvement because development sessions should follow the actual build output, not naming assumptions.
\n
This release also fixes a CLI run preset selection false positive by ensuring empty preset lists are handled before accessing the first preset.
\n
Better compiler diagnostics
\n
v2.6.3 improves compiler diagnostics for template errors originating in system headers.
\n
When possible, Vix can re-anchor those errors to the relevant project instantiation location.
\n
This matters because C++ template failures often appear deep inside standard library or third-party headers. The real mistake is usually in user code, but the compiler output may not make that obvious at first glance.
\n
Vix does not hide the compiler.
\n
It tries to make the useful part of the compiler output easier to reach.
\n
vix tests progress and interruption handling
\n
vix tests receives improvements for long CTest runs.
\n
The live progress output now shows:
\n
completed\ntotal\nrunning\nelapsed time
This makes long test sessions easier to follow.
\n
The release also fixes interruption handling so Ctrl+C is reported as a user interruption instead of being treated as a test failure.
\n
That distinction matters.
\n
A user interruption is not the same thing as a broken test suite.
\n
HTTP session hardening
\n
Vix Core receives several HTTP session fixes for edge cases.
\n
The release improves parsing and error-response behavior for:
\n
\n
malformed requests
\n
invalid content lengths
\n
oversized payloads
\n
unexpected EOF bodies
\n
\n
It also fixes HTTP keep-alive shutdown behavior for case-insensitive Connection: close handling.
\n
This kind of work is not always visible in simple examples, but it is critical for real servers.
\n
HTTP servers must behave correctly when clients send bad input, partial input, or protocol edge cases.
\n
v2.6.3 makes that layer more robust.
\n
Core lifecycle and shutdown semantics
\n
One of the most important parts of v2.6.3 is the work on Core lifecycle behavior.
\n
This release strengthens shutdown semantics across:
\n
\n
App
\n
HTTPServer
\n
RuntimeExecutor
\n
async TCP services
\n
\n
App::close() is now terminal, idempotent, and safe before or after listen().
\n
App::wait() now ensures signal-stop paths close the running server instead of only exiting the wait loop.
\n
App::listen() prevents closed app instances from being restarted accidentally.
\n
The HTTP server shutdown ordering was improved so the accept loop can drain before the async I/O context is stopped.
\n
The TCP listener is destroyed before shutting down the async context.
\n
Readiness signaling now marks the server as ready only after the accept loop has started.
\n
Metrics-thread shutdown races were also fixed by serializing metrics-thread creation with shutdown joining.
\n
This is deep infrastructure work.
\n
The result is a Core module that behaves more predictably under fast lifecycle tests, shutdown races, signal stops, and sanitizer instrumentation.
\n
Async TCP shutdown fixes
\n
The async TCP layer also receives important shutdown fixes.
\n
Async TCP stream close behavior now cancels pending operations, shuts down the socket, and closes it safely.
\n
Async TCP listener close behavior now cancels and closes the acceptor on the Asio executor.
\n
Pending accepts keep the acceptor alive until completion handlers finish.
\n
Async shutdown behavior was improved so pending Asio operations can complete and resume awaiting coroutines cleanly.
\n
The async scheduler shutdown path was also fixed so pending coroutine handles are not silently destroyed before completion paths can run.
\n
This work matters because async shutdown bugs can be intermittent and difficult to reproduce.
\n
They may pass in normal runs and fail only under sanitizer builds, Valgrind, slow machines, or CI timing conditions.
\n
v2.6.3 reduces those races.
\n
Runtime executor fixes
\n
The runtime executor receives shutdown and idle-detection fixes.
\n
Pending posted tasks are now drained before workers are stopped.
\n
Idle detection now tracks accepted in-flight tasks before they begin execution.
\n
This avoids cases where the runtime could appear idle while accepted work had not started yet.
\n
The runtime worker shutdown behavior was also fixed when yielding tasks are still being rescheduled.
\n
Together, these changes make the runtime executor more reliable under concurrent workloads, shutdown paths, and tests that depend on deterministic completion.
\n
Official Core benchmark suite
\n
v2.6.3 adds the official Vix Core benchmark suite.
\n
The suite covers both low-level runtime paths and higher-level application behavior:
The release also updates module test CMake files to consistently attach sanitizer compile and link options to test executables.
\n
This is important because sanitizer-enabled static libraries often require the final test executables to link with the required ASan/UBSan runtime flags.
\n
Without that, tests can fail at link time instead of testing the real code.
\n
Threadpool determinism
\n
The threadpool module receives several deterministic behavior fixes.
\n
Future handling for pre-cancelled and queued-cancelled tasks now resolves deterministically instead of hanging.
\n
Task handle cancellation paths now report cancellation through the associated future.
\n
Threadpool tests that assumed asynchronous work completed immediately after posting were fixed.
\n
ExecutorTest now waits for posted threadpool work to complete before checking shared state.
\n
ShutdownTest behavior expectations were fixed for the allow_after_stop submission policy.
\n
These changes matter because threadpool tests must not depend on timing luck.
\n
Concurrency tests should prove behavior, not race the scheduler.
\n
Smaller module fixes
\n
v2.6.3 also includes several focused module fixes.
\n
The game registry clear test was fixed to avoid reading a system object after Registry::clear() destroys owned systems.
\n
The time module smoke test was fixed to avoid signed integer overflow detected by UBSan.
\n
The validation module test linking was fixed by avoiding a single GoogleTest binary for plain test files that each define their own main.
\n
These fixes are small individually, but together they improve the reliability of broad module testing.
\n
Highlights
\n
\n
Fixed vix publish registry preparation and stale registry state handling.
\n
\n
Improved diagnostics when a package version already exists.
\n
\n
Fixed JSON JPath parsing after bracket segments.
\n
\n
Added dedicated JSON module CMake targets for examples, tests, and benchmarks.
\n
\n
Added JSON module benchmark snapshots.
\n
\n
Fixed vix run executable resolution for CMake projects with non-folder-name binaries.
\n
\n
Improved vix run diagnostics when multiple runnable executables are produced.
\n
\n
Updated watch mode to use shared runnable executable discovery.
\n
\n
Improved compiler diagnostics for template errors rooted in system headers.
\n
\n
Improved vix tests live progress output.
\n
\n
Fixed vix tests interruption handling for Ctrl+C.
\n
\n
Fixed HTTP session handling for malformed requests, invalid content lengths, oversized payloads, and unexpected EOF bodies.
\n
\n
Fixed case-insensitive Connection: close keep-alive shutdown behavior.
\n
\n
Strengthened Core lifecycle semantics across App, HTTPServer, RuntimeExecutor, and async TCP services.
\n
\n
Fixed App::close() so shutdown is terminal, idempotent, and safe before or after listen().
\n
\n
Fixed App::wait() signal-stop behavior.
\n
\n
Fixed App::listen() so closed app instances cannot be restarted accidentally.
\n
\n
Improved HTTP server shutdown ordering.
\n
\n
Fixed async TCP stream and listener close behavior.
\n
\n
Fixed async shutdown behavior for pending Asio operations and awaiting coroutines.
\n
\n
Fixed runtime executor shutdown so pending posted tasks drain before worker shutdown.
\n
\n
Fixed runtime executor idle detection.
\n
\n
Added the official Vix Core benchmark suite.
\n
\n
Added shared benchmark utilities and JSON report generation.
\n
\n
Added scripts/run_core_benchmarks.sh.
\n
\n
Added scripts/compare_core_benchmarks.py.
\n
\n
Added the official Core v2.6.3 Release benchmark baseline.
\n
\n
Updated Core README with benchmark workflow documentation.
\n
\n
Added strict Core CI coverage for debug builds, sanitizer builds, Valgrind, static analysis, benchmark builds, and package export validation.
\n
\n
Updated SECURITY_CI to build and run module-level tests.
\n
\n
Added broad sanitizer-ready module test coverage.
\n
\n
Fixed static-analysis scope so third-party, generated, example, benchmark, and test files are not blocking source analysis.
\n
\n
Updated cppcheck and clang-tidy scope handling.
\n
\n
Fixed sanitizer linking for many module test targets.
\n
\n
Made threadpool cancellation and shutdown tests deterministic.
\n
\n
\n
Compatibility
\n
Vix.cpp v2.6.3 is a compatibility-focused release.
\n
It does not introduce intentional breaking changes.
\n
Existing CMake projects continue to use their CMakeLists.txt.
\n
Existing Vix workflows such as:
\n
vix build\nvix run\nvix dev\nvix tests\nvix check
continue to work.
\n
The main behavior changes are improvements in correctness, diagnostics, test handling, shutdown behavior, benchmark organization, and CI scope.
\n
For projects with unusual executable output names, vix run should now behave better because runnable executable discovery no longer depends on the project folder name.
\n
For projects using long-running CTest suites, vix tests should now provide better progress visibility and cleaner interruption handling.
\n
For projects running strict CI with sanitizers or static analysis, v2.6.3 should reduce false positives and linking failures while increasing real module coverage.
\n
Notes
\n
Vix.cpp v2.6.3 is not a flashy release.
\n
It is an engineering release.
\n
It makes the runtime safer, the tests more reliable, the benchmark workflow official, the CI stricter and better scoped, and the module test story stronger.
\n
This kind of release matters because a C++ application platform cannot rely only on new features.
\n
It must also prove that the foundation is stable.
\n
Vix.cpp v2.6.3 is a step in that direction.
\n
It improves confidence in the Core runtime, the CLI workflow, the module ecosystem, and the release process itself.
\n';
+const v2_6_3 = {
+ html
+};
+export {
+ v2_6_3 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.0-C4VDlEl1.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.0-C4VDlEl1.js
new file mode 100644
index 000000000..a36b37299
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.0-C4VDlEl1.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.7.0
\n
Vix.cpp v2.7.0 introduces three new foundations for building and learning with Vix: Vix Note, Vix UI, and Vix Requests.
\n
Vix Note provides a visual workspace where C++ and Reply cells can be written, executed, saved, and exported. Vix UI introduces a server-rendered interface layer for applications that need views, forms, assets, live fragments, or WebView delivery. Vix Requests adds a built-in HTTP and HTTPS client for communicating with external APIs without introducing a separate networking library into each project.
\n
The release also changes how the Vix SDK is installed. The bootstrap installers now install the CLI only, while developers select the SDK profile that matches their project through vix upgrade --sdk.
\n
These changes give the v2.7 release line a broader application workflow without making every Vix installation carry the complete SDK by default.
\n
Release focus
\n
Vix began as a native runtime and command-line workflow for building C++ applications. As the project grew, several related needs became more visible.
\n
Learning and experimentation required a workspace more approachable than a complete application project. Web and desktop applications needed a clear interface layer rather than ad hoc HTML generation. Applications consuming external services needed a simple client API with proper HTTP, HTTPS, timeout, session, and TLS behavior.
\n
The SDK also needed a more deliberate installation model. A developer building a database application does not necessarily need game, peer-to-peer, desktop, and agent modules. Installing the complete SDK for every project made setup heavier and hid which system dependencies belonged to which domain.
\n
Vix.cpp v2.7.0 addresses these problems together.
\n
The release introduces the modules needed for visual learning, interfaces, and outbound requests, while SDK profiles make it possible to install only the relevant parts of the platform.
\n
Vix SDK profiles
\n
Vix now distributes specialized SDK profiles through:
Each profile groups the modules and system dependencies required for a particular kind of project.
\n
The web profile is intended for HTTP services, WebSocket applications, requests, middleware, templates, and related web functionality.
\n
The data profile covers database, ORM, cache, key-value, and data-oriented modules.
\n
The desktop, p2p, game, and agent profiles provide the modules associated with those application domains.
\n
The default profile provides the general SDK foundation, while all installs the complete SDK for development, validation, or projects that intentionally use modules from several areas.
\n
Discovering SDK profiles
\n
Available release profiles can be listed with:
\n
vix upgrade --sdk list
A profile can be inspected before installation:
\n
vix upgrade --sdk info web
The shorter information form is also supported:
\n
vix upgrade --sdk-info web
Profile information includes:
\n
\n
a description of the profile;
\n
the Vix modules it contains;
\n
system dependencies for the current operating system;
\n
the command used to install it;
\n
a link to the relevant documentation.
\n
\n
This allows developers to understand what an SDK profile contains before downloading it or installing additional system packages.
\n
Installing SDK profiles
\n
A profile can be installed with:
\n
vix upgrade --sdk web
Running vix upgrade --sdk without a profile selects default.
\n
Several profiles can also be installed in one command:
\n
vix upgrade --sdk web data desktop
Each profile reports its status independently. A missing release asset for one profile is shown directly rather than causing the command to finish without useful output.
\n
Profile names are validated before asset resolution, so an unknown profile produces a focused CLI error instead of a failed download request.
\n
SDK installation layout
\n
SDK profiles are installed under:
\n
~/.vix/sdk/<profile>/<version>/
Current-profile metadata is stored in:
\n
~/.vix/sdk/<profile>/current.json
A current pointer is also maintained under:
\n
~/.vix/sdk/<profile>/current
The installation metadata records the profile, Vix version, platform, installation directory, source asset, installation time, and downloaded size.
\n
Keeping versions in separate directories makes the installation state easier to inspect and prepares the SDK workflow for safer upgrades and profile lifecycle management.
\n
CLI-first installation
\n
The Unix and Windows bootstrap installers now install the Vix CLI only.
\n
After installation, the developer selects an SDK from the CLI:
\n
vix upgrade --sdk list\nvix upgrade --sdk info web\nvix upgrade --sdk web
This separates two responsibilities.
\n
The bootstrap installer is responsible for making the vix command available.
\n
The CLI is responsible for understanding Vix release assets, SDK profiles, operating systems, architectures, system dependencies, and profile metadata.
\n
This avoids duplicating SDK selection logic across shell and PowerShell installation scripts.
\n
The older --cli-only installer option remains accepted for compatibility, although CLI-only installation is now the normal behavior.
\n
Upgrade command experience
\n
vix upgrade now uses a quieter default output focused on the information required by the developer.
\n
Internal commands, temporary paths, clone operations, raw download details, and low-level diagnostics are hidden during a normal successful upgrade.
\n
Detailed output remains available with:
\n
vix upgrade --verbose
Check and dry-run modes use concise summaries:
\n
vix upgrade --check\nvix upgrade --dry-run
When checking an SDK profile, Vix verifies that the expected release asset exists instead of reporting that a profile can be installed before confirming its availability.
\n
Machine-readable output is kept separate:
\n
vix upgrade --json
In JSON mode, human progress lines are not mixed into the structured result.
\n
Vix Note
\n
Vix Note is a visual notebook for learning, demonstrating, and experimenting with C++ and Vix.cpp.
\n
It is available as the first-class SDK target:
\n
vix::note
and through the CLI:
\n
vix note
Running the command without a document starts a workspace in the current directory.
\n
An existing notebook can be opened with:
\n
vix note lesson.vixnote
The browser interface provides editable cells, execution controls, outputs, compiler errors, cell ordering, document saving, and run-all behavior.
\n
The .vixnote format
\n
Vix Note documents use the .vixnote extension and remain compatible with Markdown-oriented content.
\n
Cell boundaries and metadata are stored through comments such as:
\n
<!-- vixnote:cell ... -->
This keeps the document readable as text while preserving information required by the notebook, including stable cell identifiers, titles, types, and execution state.
Serialization now preserves stable cell identifiers and titles through load, edit, save, and reload cycles.
\n
Note cell execution
\n
The first Vix Note release supports C++ and Reply execution.
\n
C++ cells run through the existing Vix execution workflow rather than through an unrelated embedded compiler. This allows a note to use the same compiler and project context as ordinary Vix commands.
\n
Reply cells use the embedded Vix Reply runtime.
\n
The runtime session stores cell outputs and execution records so the UI can display the result associated with each cell.
\n
Note execution can also understand the surrounding Vix project. It can use the project root, vix.app, legacy manifests, dependency directories, include paths, and the correct project working directory.
\n
This makes it possible to write notebook examples that use the project’s real headers and dependencies rather than limiting Note to standalone standard-library snippets.
\n
Note workspace mode
\n
A pre-existing .vixnote file is no longer required.
\n
Running:
\n
vix note
starts a Note workspace rooted in the current directory.
\n
This is useful when beginning a lesson, exploring an existing project, or testing small pieces of code without first creating a document manually.
\n
A document can then be created and saved from the browser interface.
\n
The workflow is similar to other notebook environments while remaining connected to the native Vix project and compiler.
\n
Note API and local server
\n
Vix Note starts a local server that hosts the interface and exposes the notebook operations required by the frontend.
\n
The initial API supports:
\n
\n
loading document state;
\n
editing cells;
\n
executing one cell;
\n
executing all cells;
\n
moving cells;
\n
saving the document;
\n
retrieving execution results and errors.
\n
\n
The frontend uses these routes rather than maintaining an unrelated in-browser document model.
\n
The server also handles static assets for the Note interface.
\n
Note UI assets
\n
Vix Note can load its frontend assets from several sources.
\n
It supports project-local assets, installed assets, a custom asset directory, and an embedded fallback.
\n
A custom directory can be supplied through:
\n
VIX_NOTE_ASSET_DIR=/path/to/assets vix note
The embedded fallback ensures that Note can still start when an external asset directory is unavailable.
\n
Asset resolution covers both / and /index.html, and the server tests validate normal, installed, custom, and fallback asset behavior.
\n
Desktop Note mode
\n
Vix Note can run inside a desktop WebView shell:
\n
vix note --desktop
An existing notebook can be opened similarly:
\n
vix note lesson.vixnote --desktop
The Note server runs locally in the process, while the desktop shell opens the interface after the readiness endpoint becomes available.
\n
The shell waits for the configured server URL instead of opening immediately and displaying an unavailable page.
\n
The browser workflow remains the default. Desktop mode provides another delivery path for environments where the notebook should feel like a standalone local application.
\n
Static HTML export
\n
A .vixnote lesson can be exported as static HTML:
\n
vix note export lesson.vixnote --out lesson.html
The export produces a document that can be opened without starting the Note server.
\n
This is useful for sharing lessons, publishing examples, archiving completed notebooks, or distributing educational content where interactive execution is not required.
\n
Vix UI
\n
Vix UI introduces a server-rendered interface layer for Vix applications.
\n
It is available through:
\n
#include <vix/ui.hpp>
and through the CMake target:
\n
vix::ui
The module builds on the existing Vix template engine and HTTP response layer rather than introducing a separate client-side application framework.
\n
Its purpose is to provide the common primitives needed to generate application interfaces from C++ in a structured way.
A view describes server-rendered content and receives the context required to produce its result.
\n
HtmlResponse allows the HTTP layer to return UI output directly without requiring every route to construct low-level response bodies and headers manually.
\n
Core now supports optional UI response integration, so applications can return Vix UI views through the normal routing workflow when the UI module is enabled.
\n
HTML helpers
\n
Vix UI includes helpers for common HTML generation tasks.
\n
These cover escaping text, creating attributes, and producing small fragments without repeatedly rebuilding the same safety logic inside each application.
\n
The helpers are intended for focused rendering tasks. Larger page structures can continue to use the template system and view abstractions.
\n
Escaping remains explicit because server-rendered output must distinguish trusted markup from user-provided text.
It supports development and production asset behavior, including:
\n
\n
manifest lookup;
\n
hashed production asset paths;
\n
CSS and JavaScript grouping;
\n
preload generation;
\n
module scripts;
\n
asset versioning.
\n
\n
This allows a server-rendered application to use assets produced by a frontend build tool without hardcoding generated filenames into C++ source.
\n
In development, readable or direct paths can be used. In production, the asset manager can resolve the fingerprinted paths recorded by the build manifest.
\n
Forms
\n
Vix UI provides server-rendered form helpers for:
\n
\n
text fields;
\n
select options;
\n
checkboxes;
\n
radio buttons;
\n
file inputs;
\n
form data binding;
\n
previous submitted values;
\n
validation errors;
\n
CSRF-related fields.
\n
\n
The goal is to keep ordinary server-rendered forms practical without creating a large form framework.
\n
A validation failure can return the same view with the user’s earlier input and associated errors, instead of requiring each project to rebuild that behavior from scratch.
\n
Live fragments and notifications
\n
The module includes helpers for interfaces that update part of a page rather than rendering the complete document again.
\n
This includes support for:
\n
\n
fragments;
\n
WebSocket-friendly updates;
\n
flash messages;
\n
toast notifications.
\n
\n
These primitives are designed to work with the existing Vix HTTP and WebSocket stack.
\n
They do not require that the entire application become a client-side single-page application. A project can remain server-rendered while adding live behavior only where it is useful.
\n
PWA and mobile helpers
\n
Vix UI includes helpers for Progressive Web App metadata and mobile-oriented browser behavior.
\n
These cover:
\n
\n
viewport metadata;
\n
safe-area CSS;
\n
web application manifests;
\n
installable application meta tags.
\n
\n
The initial mobile direction is based on web interfaces and WebView delivery rather than a separate native widget system.
\n
This keeps one interface model usable in browsers, desktop shells, and mobile shells while leaving space for native UI work where it is genuinely required.
\n
Desktop shell primitives
\n
The UI module includes the lower-level components used by desktop shell workflows:
It also includes a descriptor backend for non-visual validation and a Linux WebView backend for actual desktop windows.
\n
The descriptor backend allows shell behavior to be tested in CI without opening a graphical window.
\n
Platform descriptors describe web, desktop, and mobile targets so higher-level commands can prepare the correct delivery path from one application interface.
\n
Desktop CLI workflow
\n
The CLI now provides:
\n
vix desktop
Development mode can be started with:
\n
vix desktop run
A desktop build can be prepared with:
\n
vix desktop build
A distributable directory can be created with:
\n
vix desktop package --target dir
The shell manages the relationship between the local server process and the WebView.
\n
It waits for server readiness before opening the application and cleans up server processes started by vix desktop run when the desktop shell closes.
\n
Mobile shell workflow
\n
Vix also introduces:
\n
vix mobile
The first mobile implementation generates Android WebView projects.
\n
The workflow includes project generation, wrapper handling, build, run, and device-listing commands.
\n
Generated Android projects include the launcher resources required for a valid build, and commands can be run from inside the generated Android project directory.
\n
When a Gradle wrapper is present, Vix prefers:
\n
./gradlew
over relying on a system Gradle installation.
\n
Launch behavior uses the generated application package and MainActivity.
\n
Vix Requests
\n
Vix Requests provides a built-in HTTP and HTTPS client API.
\n
It is available through:
\n
#include <vix/requests.hpp>
or:
\n
#include <vix/requests/requests.hpp>
The public target is:
\n
vix::requests
The API is designed for direct request workflows while still providing reusable clients and sessions for applications that need persistent configuration.
\n
Basic requests
\n
The module provides helpers for common HTTP methods:
The transport uses vix::async, allowing requests to participate in the existing Vix asynchronous runtime instead of introducing another scheduler or event loop.
\n
This is useful for servers and applications that need to make outbound calls without blocking the active worker.
\n
HTTPS and TLS
\n
Vix Requests supports HTTP and HTTPS transports.
\n
HTTPS uses OpenSSL with Asio-based transport execution.
\n
The implementation includes:
\n
\n
TLS handshake support;
\n
Server Name Indication;
\n
hostname verification;
\n
certificate verification enabled by default.
\n
\n
TLS verification is controlled through:
\n
RequestOptions::verify_tls
Verification can be disabled for controlled local testing, but secure verification remains the default for normal requests.
\n
The module includes HTTPS smoke validation through a local OpenSSL test server so TLS behavior can be tested without depending entirely on an external public service.
\n
Build and SDK integration
\n
The new modules are integrated into the Vix umbrella build.
\n
When enabled, the following targets are built, installed, and exported:
Release validation checks that the new public headers and static libraries are present after installation.
\n
This prevents a module from building successfully inside the repository while being absent or incomplete in the distributed SDK.
\n
CI and validation
\n
The release expands CI coverage for Note, UI, and Requests across umbrella builds, module tests, package export, SDK validation, release checks, and security-oriented configurations.
\n
Core is tested with UI support both enabled and disabled so the optional response integration does not become an unconditional dependency.
\n
Vix Requests is built, tested, installed, and consumed through its exported package configuration.
\n
HTTP integration tests run against local test services, while HTTPS behavior is validated through a local OpenSSL server.
\n
Vix Note tests cover document parsing, stable metadata, local routes, cell execution, run-all behavior, asset loading, custom asset directories, save and reload behavior, and workspace startup.
\n
Desktop shell tests use the descriptor backend in automated environments instead of opening a real Linux WebView window.
\n
Mobile validation covers generated Android resources, Gradle wrapper selection, project detection, building, and application launch metadata.
\n
Performance signal
\n
As part of the v2.7.0 validation work, the Vix HTTP runtime was measured with a local benchmark on an HP EliteBook running Linux on x86_64 with eight CPU threads.
\n
The benchmark used wrk against a small local /bench route:
This result is included as a local performance signal for the v2.7 runtime rather than as a universal throughput claim. HTTP performance depends on the application route, compiler, build configuration, operating system, hardware, connection settings, and benchmark methodology.
\n
The benchmark nevertheless confirms that the new Note, UI, Requests, SDK, desktop, and mobile work did not require turning the underlying HTTP runtime into a heavier execution path.
\n
Note fixes
\n
Several issues found during the Vix Note integration were corrected before the release.
\n
Cell identifiers are preserved after editing and saving a notebook.
\n
The command can start from the current directory without an existing note file.
\n
Asset resolution now works across custom directories, environment overrides, installed files, and embedded fallback assets.
\n
Desktop Note mode starts the server in process and waits until it is ready before opening the WebView.
\n
C++ cell execution avoids unnecessary clean rebuilds during ordinary runs, keeping notebook iteration practical.
\n
UI shell fixes
\n
Desktop shell startup now waits for the configured readiness URL before opening.
\n
The shell handles the case where the readiness endpoint is already used by another process rather than blindly starting a duplicate service.
\n
Processes launched by vix desktop run are cleaned up when the shell closes.
\n
Android generation now includes the launcher icon resources needed by the generated application.
\n
Mobile build, run, and wrapper commands recognize the generated project even when invoked from inside its Android directory.
\n
Upgrade fixes
\n
The new SDK workflow also corrects several command-line presentation and validation problems.
\n
Unavailable profile assets are reported directly during dry runs and checks.
\n
Unknown profile names fail before asset lookup.
\n
Multi-profile commands produce visible status for each profile.
\n
Important labels and commands use readable terminal contrast.
\n
Module lists and system dependency commands are formatted as normal readable terminal content rather than low-contrast decorative text.
\n
Extra blank lines before the shell prompt have been removed.
They were replaced by the more complete C++, Reply, and HTML learning examples introduced with the stable Note foundation.
\n
Removing the prototypes avoids keeping examples that describe an earlier document structure or execution model.
\n
Compatibility
\n
Existing Vix projects remain compatible with the release.
\n
The new modules are optional and are included only when enabled by the selected SDK and build configuration.
\n
Projects that do not use UI retain the existing Core HTTP response behavior.
\n
The install scripts continue to make the CLI available, but developers must now select an SDK profile through vix upgrade --sdk when SDK headers and libraries are required.
\n
The --cli-only installer option remains recognized for older automation.
\n
Projects that need the complete SDK can continue to use:
\n
vix upgrade --sdk all
Projects with focused requirements can install a smaller profile instead.
\n
Known limitations
\n
Vix Note v1.0.0 provides the notebook foundation but does not yet include the later package-based extension system. The first release supports the built-in cell and runtime model.
\n
C++ cells execute native code and should be treated with the same care as running a local executable. Stronger timeout and output guards are introduced in v2.7.2.
\n
Vix UI is primarily a server-rendered interface system. It does not attempt to replace full client-side frameworks when an application genuinely requires a large browser runtime.
\n
The Linux WebView backend is the first native desktop shell implementation. Platform support depends on the available shell backend and system libraries.
\n
The initial mobile workflow targets Android WebView projects. It is not a complete cross-platform native mobile toolkit.
\n
Vix Requests provides the common HTTP and HTTPS client workflow, but specialized protocol clients may still require application-specific wrappers.
\n
SDK profiles in this release can be installed side by side, but full automatic composition of modules from several profiles is completed in v2.7.4.
\n
Release summary
\n
Vix.cpp v2.7.0 expands the platform in three clear directions.
\n
Vix Note creates a visual environment for learning, documenting, and running C++ code while remaining connected to real Vix projects.
\n
Vix UI provides the server-rendered primitives needed to build interfaces, forms, asset pipelines, live fragments, PWAs, and WebView-delivered applications.
\n
Vix Requests gives applications a standard way to communicate with HTTP and HTTPS services using direct calls, reusable sessions, asynchronous APIs, and secure TLS defaults.
\n
The new SDK profile workflow makes these capabilities available without requiring every installation to carry the complete platform.
\n
Developers install the CLI first, inspect the available profiles, and then install the SDK that matches the project they are building.
\n
This release establishes the main foundations extended throughout the rest of the v2.7 line: App Modules, module dependencies, Cloud integration, SDK composition, safer package workflows, and package-based Vix Note extensions.
\n';
+const v2_7_0 = {
+ html
+};
+export {
+ v2_7_0 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.1-DxRDQGw1.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.1-DxRDQGw1.js
new file mode 100644
index 000000000..8eec1683f
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.1-DxRDQGw1.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.7.1
\n
Vix.cpp v2.7.1 introduces the first complete foundation for Vix App Modules.
\n
Applications and backend projects can now declare internal modules in vix.app, enable or disable them from one place, generate module-specific source structures, wire enabled modules into the executable automatically, and validate architectural problems before they become build failures.
\n
The release also updates vix dev so changes to vix.app trigger the configuration work required to regenerate module wiring. SDK lifecycle handling and vix uninstall receive a broader command workflow for inspecting and removing CLI installations, SDK profiles, and globally installed packages.
\n
Release focus
\n
A small C++ application can remain understandable with one executable target and a compact src/ directory. As the project grows, that structure often becomes less clear.
\n
Authentication, projects, package management, storage, billing, build history, administration, and other areas begin to share the same source tree. Routes are registered from several places, tests lose their connection to the feature they cover, and disabling one part of the application may require manual edits across CMake, startup code, and source files.
\n
Vix App Modules provide an internal organization layer for this kind of project.
\n
A module belongs to one application. It can contain its own source files, routes, controller, tests, migrations, and metadata, while the application keeps one executable, one dependency graph, and one main runtime.
\n
This is different from creating an independent library for every feature. Internal modules are intended to organize one application without forcing each feature to become a separately versioned or installed package.
\n
Declaring modules in vix.app
\n
Application modules are declared through [module.<name>] sections in vix.app.
This states that projects is active and requires the auth module.
\n
The declaration is part of the application manifest because module activation is an application-level decision. A module directory may exist on disk without participating in every build.
\n
Application manifest support
\n
The vix.app loader now parses module declarations into structured application metadata.
This metadata is used consistently by module listing, validation, generated CMake, runtime wiring, dev-mode rebuild decisions, and CLI module commands.
\n
The application manifest also supports:
\n
type = "backend"
A backend application is mapped internally to an executable target. This gives backend projects the same module-aware generated build path as other executable vix.app applications.
\n
Creating an application module
\n
A module can be created with:
\n
vix modules add auth
Inside a vix.app project, the command now performs more than creating a folder.
\n
It generates the module structure, writes a vix.module manifest, creates a test file, and registers the new module in the root vix.app.
\n
The developer does not need to add the [module.auth] section manually after generation.
\n
The exact generated structure depends on the application type. Backend projects receive a backend-oriented module, while general application projects receive a routed service module.
\n
Backend module generation
\n
Inside a backend project, vix modules add generates a module prepared for routes, controllers, migrations, tests, and future data or service layers.
The generated controller and module provide a small working route rather than an empty placeholder.
\n
This allows the module to compile, register itself, and demonstrate the expected application integration immediately after creation.
\n
The initial skeleton remains deliberately small. It creates the boundaries required by the workflow without deciding that every backend module must use a particular repository, service, model, or persistence architecture.
\n
Those layers can be added when the module actually needs them.
\n
Service modules for application projects
\n
General executable app projects receive routed service modules.
The generated example includes route registration and a minimal HTTP response so the developer can verify that the module is active.
\n
Service modules are recorded with:
\n
kind = "service"
This allows generated application wiring to distinguish them from unrelated source folders and include them in route registration.
\n
The module remains part of the main application runtime. It does not create a separate server process or executable.
\n
Module manifests
\n
Every generated module receives a vix.module file.
\n
The manifest describes the module itself rather than its application-level activation state.
\n
A basic generated manifest can contain:
\n
name = "auth"\nkind = "backend"\n\n[routes]\nprefix = "/api/auth"\n\n[tests]\nenabled = true
The root vix.app decides whether the module is enabled and where it lives. The module manifest describes details that belong to the module, such as its kind, route prefix, and test configuration.
\n
This separation allows module metadata to stay close to the module source while keeping the active application composition visible from one root file.
\n
Enabling and disabling modules
\n
Declared modules can be activated through the CLI:
\n
vix modules enable auth
They can be disabled with:
\n
vix modules disable auth
These commands update the corresponding enabled value in vix.app.
\n
A disabled module can remain in the repository without being compiled or linked. Its files, tests, and manifest stay available for later use, but it does not participate in the current application.
\n
This is useful for optional features, experimental work, deployment variants, and modules that are temporarily unavailable while another part of the project is being changed.
\n
Disabling a module is not implemented by deleting its CMake files or commenting out startup code. The application manifest remains the source of truth.
\n
Listing application modules
\n
The active module state can be inspected with:
\n
vix modules list
The output includes the declared module name, enabled state, kind, configured path, filesystem status, and internal dependencies.
\n
This helps distinguish several conditions that would otherwise look similar during a build:
\n
\n
a module is declared and enabled;
\n
a module is declared but disabled;
\n
a module is declared but missing on disk;
\n
a directory exists but is not declared;
\n
a module depends on another module.
\n
\n
The command reflects vix.app, not every arbitrary folder found under modules/.
\n
Enabled-module build generation
\n
Generated vix.app CMake projects now load only the modules enabled in the application manifest.
\n
Vix emits the active set through:
\n
VIX_ENABLED_MODULES
This list controls which module directories are added to the generated build.
\n
An empty list is emitted explicitly when no modules are enabled. This is important because the absence of the variable could otherwise cause the older CMake fallback to load every directory under modules/.
\n
The behavior now differs intentionally between project types:
The generated implementation includes the enabled routed modules and provides the registration code used by the application startup path.
\n
For executable vix.app targets, vix_app_modules.cpp is added automatically to the generated CMake target.
\n
The application template keeps a small integration point rather than requiring developers to modify src/main.cpp whenever a module is added or disabled.
\n
This allows the root application bootstrap to remain stable while module registration follows the manifest.
\n
Module registry integration
\n
Generated app projects now include a small module registry layer:
The registry provides a clear point where generated module registration and application startup meet.
\n
The goal is not to hide module construction behind a large runtime framework. It is to prevent the main source file from becoming a manually maintained list of every route and feature in the application.
\n
A typical application entry point can initialize its core runtime and delegate module registration to the registry.
\n
When the module set changes, Vix regenerates the application module wiring without requiring the developer to rewrite the main bootstrap.
\n
Route registration
\n
Enabled routed modules register their routes automatically.
\n
For a module with:
\n
[routes]\nprefix = "/api/auth"
the generated application wiring includes the module registration hook associated with that route group.
\n
When the module is disabled, its generated registration disappears from the active build. The route is no longer available because the module itself is not compiled or wired into the executable.
\n
This behavior was validated for both service modules in app projects and backend modules in backend projects.
\n
Route availability therefore follows the same activation state as compilation and linking.
\n
Internal module dependencies
\n
Modules can declare dependencies on other modules:
Internal dependencies describe application structure rather than registry packages.
\n
The declaration says that the projects module expects the auth module to participate in the same application.
\n
Vix validates these relationships before the generated build is configured.
\n
An enabled module cannot depend on an undeclared module, and it cannot depend on a module that is currently disabled.
\n
This prevents application configurations where compilation succeeds partially but required runtime behavior is absent.
\n
Circular dependency detection
\n
vix modules check now detects circular internal dependencies.
\n
For example:
\n
auth depends on projects\nprojects depends on auth
This structure is rejected before CMake generation.
\n
Circular module relationships usually indicate that the boundary between two features is unclear or that shared behavior should move into a lower-level module.
\n
Detecting the cycle at the manifest level gives the developer a direct architectural error rather than allowing the relationship to emerge later through include paths, link order, or runtime initialization.
\n
Module validation
\n
The module checker now validates the complete relationship between vix.app, the filesystem, module manifests, and internal dependencies.
\n
Run:
\n
vix modules check
The command reports conditions such as:
\n
declared module missing on disk\nenabled module missing CMakeLists.txt\nenabled module missing vix.module\nmodule directory not declared in vix.app\ndependency on an undeclared module\ndependency on a disabled module\ncircular module dependency\nduplicate route prefix
These checks are intended to catch architectural drift early.
\n
Without them, a module may appear in the source tree but never compile, two modules may register the same route prefix, or a disabled dependency may leave another feature in an invalid state.
\n
Duplicate route prefixes
\n
Vix now checks route prefixes declared in enabled module manifests.
\n
Two modules declaring the same prefix can create ambiguous or order-dependent route behavior.
The check happens before runtime registration, where the resulting behavior would be harder to understand.
\n
Generated module tests
\n
New modules include a test file by default.
\n
Generated CMake creates module test targets when the application test option is enabled:
\n
<app>_BUILD_TESTS
The generated application CMake now declares its test options before module directories are loaded.
\n
This ordering is important because modules decide whether to create their test targets while their CMake files are being evaluated.
\n
Previously, the application test option could be introduced after the modules had already been processed, causing valid module tests to be skipped.
\n
Module tests can now be discovered and run through:
\n
vix tests
The generated test provides a starting point and confirms that the module target participates correctly in the application build.
\n
Dev mode and manifest changes
\n
vix dev now treats vix.app as an active project configuration file.
\n
A source or header change can continue through the fast rebuild path. The existing generated CMake structure remains valid, so Vix rebuilds and restarts the application without repeating unnecessary project generation.
\n
A change to vix.app is different.
\n
Enabling a module, disabling a module, changing a module path, or editing the application target can alter generated CMake and module wiring.
\n
Vix now recognizes this distinction:
\n
source or header change:\n fast rebuild\n\nvix.app change:\n regenerate, reconfigure, rebuild, restart
This makes dev mode follow the real project state rather than continuing to run an executable generated from an older manifest.
The project is then reconfigured before rebuilding.
\n
This fixes cases where editing the module list appeared to have no effect during watch mode because the previous fast rebuild path did not revisit application generation.
\n
The developer can now enable or disable a module while vix dev is active and receive an application built from the updated manifest.
\n
SDK lifecycle improvements
\n
This release also improves how installed SDK profiles are registered and removed.
\n
SDK upgrades now register installed profiles with the CMake user package registry.
\n
This helps CMake-based consumer projects locate the installed SDK through the expected package discovery mechanisms.
\n
The uninstall workflow removes the related SDK state rather than deleting only the main installation directory.
Each module can keep its own manifest, routes, controller, implementation, migrations, and tests.
\n
The application bootstrap remains responsible for shared runtime configuration, server startup, global middleware, and infrastructure used across modules.
\n
Feature-specific behavior remains inside the module that owns it.
\n
The model is intentionally internal to the application. It provides structure without requiring a distributed system, plugin runtime, or separate package for every feature.
During vix dev, the manifest change triggers application regeneration and removes the disabled module from the active executable.
\n
Validation
\n
The App Modules workflow was validated across manifest parsing, generation, CMake integration, runtime registration, module state changes, tests, and development mode.
\n
Coverage includes:
\n
\n
parsing [module.<name>] sections;
\n
enabled and disabled module state;
\n
custom module paths;
\n
service and backend module kinds;
\n
internal dependency lists;
\n
automatic registration in vix.app;
\n
vix.module generation;
\n
generated controller and route files;
\n
backend migration directories;
\n
generated test files;
\n
ModuleRegistry generation;
\n
vix_app_modules.hpp and vix_app_modules.cpp;
\n
executable target integration;
\n
automatic route registration;
\n
empty enabled-module lists;
\n
exclusion of disabled modules;
\n
legacy loading compatibility for classic CMake projects;
\n
missing module directories;
\n
missing CMakeLists.txt;
\n
missing vix.module;
\n
undeclared folders;
\n
disabled dependencies;
\n
undeclared dependencies;
\n
circular dependencies;
\n
duplicate route prefixes;
\n
module test discovery through vix tests;
\n
manifest-aware rebuilds through vix dev.
\n
\n
The uninstall workflow was validated for SDK profile listing, single-profile removal, complete SDK cleanup, global package removal, dry-run behavior, JSON output, explicit installation paths, and stale shell-path detection.
\n
Compatibility
\n
Classic CMake projects can continue to load modules through the existing modules/* convention.
\n
The stricter enabled-module behavior applies to projects using vix.app, where the manifest is now the authoritative source of application composition.
\n
Existing vix.app projects without module declarations remain valid. Their generated executable workflow continues without requiring a modules/ directory.
\n
Generated modules remain ordinary C++ and CMake source directories. Developers can inspect and modify their files without relying on a hidden binary format or runtime service.
\n
SDK uninstall commands do not remove the Vix CLI unless the broader CLI uninstall option is selected.
\n
Existing global package installations remain compatible with the improved uninstall manifest cleanup.
\n
Known limitations
\n
Vix App Modules in this release are internal application modules. They are not independently published registry packages.
\n
The first generated structures focus on routed service and backend modules. More specialized module workflows can be added later without changing the manifest foundation.
\n
Internal dependencies are validated for declaration, activation state, and cycles, but this release does not yet provide module-level registry package declarations. External package ownership inside modules is introduced in v2.7.2.
\n
Generated route registration assumes the standard Vix application and backend startup model. Projects with heavily customized bootstraps may need to connect the generated module registry at their own integration point.
\n
Disabling a module removes it from compilation and generated registration, but it does not delete its source files or migration history.
\n
Release summary
\n
Vix.cpp v2.7.1 gives C++ applications a manifest-driven internal module structure.
\n
Modules can be declared, generated, enabled, disabled, listed, validated, tested, and wired into the application without maintaining separate registration code in main.cpp.
\n
Backend projects receive feature-oriented module skeletons with controllers, routes, migrations, and tests. General applications receive routed service modules connected through a small generated module registry.
\n
vix dev now understands that application manifest changes can alter the generated build and performs the required regeneration instead of treating them like ordinary source edits.
\n
The release also improves SDK registration and expands vix uninstall into a clearer workflow for CLI installations, SDK profiles, and global packages.
\n
This establishes the application module foundation extended by later v2.7 releases with module-level package dependencies and generated WebSocket workflows.
\n';
+const v2_7_1 = {
+ html
+};
+export {
+ v2_7_1 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.2-D2bAsvFv.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.2-D2bAsvFv.js
new file mode 100644
index 000000000..6cb1aa027
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.2-D2bAsvFv.js
@@ -0,0 +1,258 @@
+const html = `
+
Vix.cpp v2.7.2
+
Vix.cpp v2.7.2 completes the dependency workflow introduced with Vix App Modules.
+
A module can now declare the registry packages it needs in its own vix.module file, while the application continues to resolve one effective dependency graph and maintain one root vix.lock.
+
The release also makes C++ cell execution in Vix Note safer. Programs that do not terminate or produce excessive output are now stopped before they can block the notebook interface.
+
Together, these changes strengthen two parts of Vix that execute user-defined work: application modules can depend on external packages without becoming separate projects, and Note cells can fail without taking the surrounding development environment with them.
+
Release focus
+
Vix App Modules were introduced in v2.7.1 to give larger applications a clearer internal structure.
+
A project can divide routes, services, controllers, storage code, and runtime behavior into modules while keeping one application entry point and one build. Each module has its own vix.module file, and vix.app decides which modules participate in the current application.
+
The first module release covered module discovery, enablement, build generation, and runtime participation. It did not yet provide a complete answer for packages used by only one module.
+
A package could be added to the root application, but that lost useful ownership information. An authentication module might be the only part of the project using rix/rix, yet the dependency appeared to belong to the entire application and was linked at the application level.
+
Vix.cpp v2.7.2 allows the module to declare that dependency directly.
+
The application still owns package resolution. Modules do not create independent lockfiles, dependency directories, or package environments. Instead, dependencies from enabled modules are merged into the application’s effective dependency set and resolved through the root project.
+
Module-level registry dependencies
+
A module can now declare registry packages in its vix.module manifest:
The registry list describes the packages required by the module.
+
The links list describes the CMake targets from those packages that must be linked to the generated module target.
+
Keeping these two pieces of information in the module manifest makes the dependency relationship explicit. A developer reading modules/auth/vix.module can see both the external package required by the module and the target used by its C++ implementation.
+
The module does not receive its own vix.lock. Its package requirement is resolved as part of the root application dependency graph.
+
Adding a package to a module
+
The vix add command now accepts a module target:
+
vix add rix/rix --module auth
The short form is also supported:
+
vix add rix/rix -m auth
Assignment-style syntax can be used in scripts:
+
vix add rix/rix --module=auth
The command updates:
+
modules/auth/vix.module
rather than adding the package to the root application manifest.
+
After updating the module, Vix refreshes the root lockfile so the new dependency is immediately part of the reproducible project state.
There is no separate module installation command and no second dependency resolver inside the module.
+
Explicit link targets
+
A package can expose one or more CMake targets. When Vix cannot determine the intended target from the package name alone, it can be supplied explicitly:
For common package names, Vix can infer a default target:
+
rix/rix -> rix::rix
The inferred or explicit target is written to the module’s links list.
+
This separation matters because a registry package name and a CMake target are related but not identical concepts. The package identifies what Vix resolves and installs. The target identifies what CMake links into the module.
+
One application dependency graph
+
Dependencies declared by enabled modules are merged with the root project dependencies before resolution.
Vix builds one effective dependency set from the application and its enabled modules. That set is resolved together and written to the root:
+
vix.lock
This preserves a single version decision for each package across the project.
+
Two modules cannot silently resolve incompatible copies of the same registry dependency in isolated lockfiles. Version conflicts are handled at the application boundary, where the complete dependency graph is visible.
+
This also keeps source control straightforward. The repository contains one lockfile representing the exact package state required by the active application configuration.
+
Enabled and disabled modules
+
Only dependencies from enabled modules participate in the active dependency graph.
+
If a module exists in the project but is disabled in vix.app, its registry requirements do not force packages into the current installation or build.
+
This follows the same rule used for module compilation and runtime generation. A disabled module remains part of the source tree, but it is not part of the active application.
+
The behavior is useful for optional features and project variants. A project can keep an integration module in the repository without requiring every developer or deployment profile to install its external dependencies.
+
When the module is enabled again, its requirements return to the effective dependency set and are resolved through the root lockfile.
+
Root lockfile generation
+
vix add --module now refreshes the root vix.lock after modifying the module manifest.
+
Earlier implementations could write the package into vix.module without creating or updating the root lockfile. The module declaration was therefore valid, but the project had no resolved package state for vix install to consume.
+
Vix.cpp v2.7.2 closes that gap.
+
The command sequence now has a consistent meaning:
+
vix add --module declares the dependency and refreshes resolution
+vix install materializes the resolved dependency graph
+vix build loads package targets and compiles the modules
The root lockfile remains the authoritative record of selected versions, commits, integrity information, and transitive dependencies.
+
Module CMake links
+
The generated application CMake now records link targets for each module.
+
For an auth module using rix::rix, Vix can generate:
+
set(VIX_MODULE_auth_LINKS
+ rix::rix
+)
The package target is linked to the generated target for auth, not automatically to the main application executable.
+
This preserves dependency ownership in the build graph.
+
A package used only by one module does not become a direct link dependency of every other module or of unrelated application code. Its include directories, compile definitions, and transitive link interface flow through the module that actually consumes it.
+
This is especially useful as applications grow. Module boundaries are more meaningful when dependencies follow those boundaries instead of accumulating on one global target.
+
Dependency loading order
+
Registry package targets must exist before module targets attempt to link them.
+
Vix now includes:
+
.vix/vix_deps.cmake
before enabled modules are added to the generated application build.
+
The order is therefore:
+
1. load resolved registry package targets
+2. generate enabled module targets
+3. link package targets to their modules
+4. generate the application runtime and executable
Previously, packages could be installed correctly but still fail during vix build because the module’s target_link_libraries() call was evaluated before targets such as rix::rix had been defined.
+
The resulting CMake error often appeared as:
+
missing: rix::rix
The package itself was present. The problem was that it entered the generated build too late.
+
The updated generation order makes module dependency declarations usable through the normal build flow.
+
Generated dependency integration
+
The generated application CMake includes .vix/vix_deps.cmake when at least one active dependency requires it.
+
This condition now considers dependencies declared by enabled modules as well as dependencies declared at the root application level.
+
A project containing only module-level registry packages therefore receives the same dependency initialization as a project with root dependencies.
+
This removes the previous assumption that the root manifest had to contain a package before generated dependency CMake would be loaded.
+
Module dependency validation
+
Vix now validates the relationship between registry packages and module link targets.
+
A module that declares a registry package but provides no corresponding link information may be incomplete. The package would be installed, but the module might never consume its exported target.
+
The opposite case is also checked. A module should not declare an external link target without a package requirement capable of providing it.
+
These checks do not assume that package names and target names must have identical spelling. They verify that the manifest contains a coherent dependency description and report incomplete metadata before CMake produces a less useful unresolved-target error.
+
Validation also covers malformed dependency entries and unsafe combinations inside the [deps] section.
+
Project-level compatibility
+
The existing root dependency workflow remains unchanged:
+
vix add rix/rix
Without --module, the dependency is added to the root project as before.
+
The two forms now express different ownership:
+
vix add rix/rix
means that the package belongs to the application dependency set directly.
+
vix add rix/rix --module auth
means that the auth module owns the declaration and link relationship.
+
Both dependency sources are resolved into the same root lockfile.
+
Application and module responsibilities
+
The module dependency design keeps each project file responsible for one part of the workflow.
+
vix.app determines which modules belong to the active application:
The root vix.lock records the exact package resolution for the application and all enabled modules.
+
vix install materializes that locked graph.
+
vix build loads the resulting package targets before generating and compiling the active modules.
+
This model gives modules local ownership without turning them into independent package-management islands.
+
Vix Note execution guards
+
Vix Note executes C++ cells as native programs.
+
That is useful because a notebook can compile and run real C++ rather than evaluating a restricted approximation of the language. It also means the code can behave like any native program, including entering an infinite loop or writing output without stopping.
+
Before this release, a cell containing non-terminating code could leave the execution request waiting indefinitely. A program producing a very large stream of output could also consume memory and make the browser interface unresponsive.
+
Vix.cpp v2.7.2 adds timeout and output-size guards around C++ cell execution.
+
These safeguards do not attempt to prove whether a program is correct. They put practical limits around one notebook execution so a bad cell does not prevent the user from continuing to work.
+
Execution timeout
+
C++ cell execution now has a time limit.
+
When a program does not terminate before the configured deadline, Vix Note stops the child process and returns a controlled execution result.
+
This covers accidental infinite loops, blocked programs, and code waiting indefinitely for input or another condition that the notebook environment cannot satisfy.
+
The timeout applies to the execution process rather than compilation. Compiler diagnostics still return normally when the source does not build.
+
A timed-out program is reported as an execution failure, allowing the notebook to recover and accept another cell run.
+
Output capture limit
+
Vix Note now limits how much output can be captured from a C++ cell.
+
Consider this program:
+
#include <iostream>
+#include <vector>
+
+int main()
+{
+ std::vector<int> v;
+
+ for (int i = 0; i < v.size() - 1; i++)
+ {
+ std::cout << i << '\\n';
+ }
+
+ return 0;
+}
v.size() returns an unsigned value. When the vector is empty, subtracting one underflows and produces a very large value.
+
The loop can therefore print far more output than the author expected.
+
Vix Note now stops the execution when captured output reaches the allowed limit. The oversized result is not sent in full to the browser.
+
This protects the server process, the HTTP response, and the notebook frontend from one unexpectedly noisy cell.
+
Recoverable cell failures
+
Timeout and output-limit failures are treated as failures of the current cell execution, not failures of the complete Note session.
+
The user can inspect the result, correct the source, and run the cell again.
+
This distinction is important in an interactive notebook. User code is expected to be incomplete or incorrect during development. The surrounding tool should contain those failures and remain usable.
+
The guards do not make arbitrary native code completely isolated. They address the two immediate cases that previously caused visible blocking: non-terminating execution and unbounded captured output.
+
Warning cleanup
+
Vix.cpp v2.7.2 also removes remaining compiler warnings from the affected code paths.
+
Vix Note runtime and web route code had sign-conversion warnings where signed and unsigned values crossed API boundaries.
+
The Note web server also contained socket-length conversions that could produce warnings on supported compilers and platforms.
+
These conversions are now handled explicitly.
+
Additional warnings across the Vix build were corrected so normal project compilation and CI logs remain focused on actionable problems.
+
A warning-free build is not only cosmetic. It makes new warnings visible when they are introduced and reduces the chance that unsafe conversions become accepted as ordinary build noise.
+
Fixed workflow gaps
+
This release fixes several failures that came from the incomplete connection between module manifests and the root dependency system.
+
vix add --module now updates the root lockfile instead of leaving the project without a resolved dependency state.
+
vix install now works when every registry dependency originates from modules and the root application contains no direct package declaration.
+
Generated builds load installed package targets before module CMake is evaluated.
+
Module link targets from vix.module are applied to the generated module that owns them.
+
Disabled modules no longer introduce inactive package requirements.
+
Together, these changes complete the path from declaration to compilation:
Regression coverage was added for module dependency declaration, root lockfile generation, installation, CMake generation, and target linking.
+
The tests cover:
+
+
adding a package with --module;
+
short -m syntax;
+
assignment-style --module=<name>;
+
explicit --link;
+
default target inference;
+
updates to the correct vix.module;
+
root lockfile creation and refresh;
+
dependencies from several enabled modules;
+
exclusion of disabled-module dependencies;
+
generation of module-specific link variables;
+
loading .vix/vix_deps.cmake before module targets;
+
successful resolution of package targets such as rix::rix;
+
invalid package and link declarations;
+
project-level vix add compatibility.
+
+
Vix Note validation covers:
+
+
non-terminating C++ cells;
+
processes exceeding the execution timeout;
+
programs producing excessive output;
+
output truncation before browser delivery;
+
recovery of the notebook after a guarded execution;
+
normal C++ cells completing inside the configured limits.
+
+
The full project was also rebuilt after warning cleanup to verify that the updated code paths compile without the previous conversion warnings.
+
Compatibility
+
Existing projects with root registry dependencies continue to use the same vix add, vix install, and vix build workflow.
+
Existing modules without a [deps] section remain valid.
+
Module dependencies are additive. A project can keep shared dependencies at the root while moving feature-specific packages into the modules that use them.
+
The application continues to maintain one root vix.lock. This release does not introduce nested module lockfiles or separate dependency installations under each module directory.
+
Projects that disable a module may see its exclusive packages removed from the effective dependency graph the next time the root lockfile is refreshed. Re-enabling the module restores those requirements.
+
Vix Note continues to compile and run ordinary C++ cells normally. Timeout and output limits affect only executions that exceed the configured safety boundaries.
+
Known limitations
+
Module-level dependencies currently use the application’s registry dependency system. They do not make a module independently publishable or installable as a separate package.
+
The links list remains explicit metadata. Vix can infer common target names, but packages exposing several possible public targets may still require --link.
+
Dependencies are resolved globally, so incompatible version requirements from two enabled modules must be reconciled at the application level. Modules do not receive isolated package versions.
+
Vix Note execution guards limit runtime duration and captured output, but they are not a complete operating-system sandbox. Native code can still access resources permitted to the Vix Note process.
+
More advanced isolation, resource accounting, and interactive process control require additional runtime work beyond this release.
+
Release summary
+
Vix.cpp v2.7.2 gives App Modules ownership of their external package requirements without fragmenting the project dependency model.
+
A module can declare registry packages and CMake links in vix.module. Enabled module requirements are merged into the application graph, resolved through one root vix.lock, installed once, and linked only to the module that needs them.
+
The release also makes Vix Note more resilient when native C++ cells do not behave as expected. Execution timeouts and output limits keep an infinite loop or excessive output from blocking the notebook.
+
With the remaining compiler warnings removed, v2.7.2 provides a cleaner and more reliable foundation for the module and notebook workflows introduced in the v2.7 release line.
+`;
+const v2_7_2 = {
+ html
+};
+export {
+ v2_7_2 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.3-DG_QSQnn.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.3-DG_QSQnn.js
new file mode 100644
index 000000000..9b8a3ca4f
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.3-DG_QSQnn.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.7.3
\n
Vix.cpp v2.7.3 expands the CLI workflow around application modules, backend projects, package management, and Softadastra Cloud.
\n
The release adds generated WebSocket modules that integrate with vix.app, introduces an API-only backend template for projects with separately hosted frontends, and provides the first complete CLI path for connecting a local Vix project to Softadastra Cloud.
\n
It also improves the package workflow beyond the registry. Git repositories can now be installed directly as project dependencies, command-line packages can be installed globally into a user-managed Vix prefix, and single C++ files can use temporary dependencies without turning the current directory into a permanent project.
\n
Public registry publishing receives stricter source and identity validation so published metadata is derived from the exact tagged revision rather than the developer’s current working tree.
\n
Release focus
\n
The main direction of v2.7.3 is to make Vix workflows connect more naturally.
\n
Application modules should not only generate files; they should participate correctly in project startup and builds. Packages should not only resolve from the public registry; developers should also be able to experiment with Git repositories and install useful command-line tools globally. Cloud integration should provide shared project state without moving compilation away from the developer’s machine.
\n
These areas meet in the CLI.
\n
Vix already knew how to create projects, resolve packages, build applications, run tests, and generate application modules. This release extends that model so the same commands can also prepare WebSocket runtimes, initialize existing directories, publish private packages, upload lockfiles, report local builds, and inspect tagged source before a public release.
\n
The result is not one isolated feature. It is a broader project workflow in which local development, reusable packages, generated modules, and optional cloud coordination follow the same project metadata.
\n
Softadastra Cloud CLI integration
\n
Vix.cpp v2.7.3 introduces the first Softadastra Cloud commands in the Vix CLI.
vix login authenticates the developer with Softadastra Cloud and stores the resulting session in the global Vix configuration.
\n
vix cloud init links the current local project to a Cloud workspace and project record. The link is stored under:
\n
.vix/cloud.json
This project-local file identifies the Cloud workspace and project associated with the current source tree.
\n
Authentication and project identity are intentionally stored in different places. The user session belongs to the developer’s Vix environment and can be reused across projects, while the Cloud link belongs to one repository.
\n
This allows a developer to work with several Cloud-linked projects without repeating login for each one and without embedding account credentials in project files.
\n
Local-first Cloud workflow
\n
Softadastra Cloud does not replace the local Vix build system.
\n
Source files, compiler execution, generated objects, build directories, package checkouts, and native binaries remain on the developer’s machine or in the project’s own CI environment.
\n
The Cloud integration records the parts of project state that are useful to share:
\n
\n
workspace and project identity;
\n
private package versions;
\n
dependency lockfiles;
\n
build reports;
\n
project permissions;
\n
team activity.
\n
\n
This distinction is visible in the CLI. vix build still performs a normal local build. Adding --report submits information after that build; it does not upload the source code for remote compilation.
\n
Similarly, vix cloud lockfile upload records the dependency state selected by the local project without changing how those dependencies are resolved or installed.
\n
Cloud status and project linking
\n
After authentication, the current environment can be inspected with:
\n
vix cloud status
The command reports whether the user is authenticated, whether the current directory is linked to a Cloud project, and which workspace and project are active.
\n
A local project can be connected with:
\n
vix cloud init
The CLI uses the authenticated account to retrieve available workspaces and creates or selects the Cloud project associated with the current source tree.
\n
Project metadata remains explicit. Vix does not assume that every local directory should be uploaded or linked merely because the user is authenticated.
\n
vix cloud sync refreshes the Cloud-side project metadata associated with the local link while preserving the local project as the source of the build workflow.
\n
Lockfile upload
\n
Cloud-linked projects can upload their dependency lockfile with:
\n
vix cloud lockfile upload
The shorter alias is also available:
\n
vix cloud lock upload
By default, the command uses the project’s normal lockfile. A different file can be selected explicitly:
\n
vix cloud lockfile upload --file vix.lock
Machine-readable output is available with:
\n
vix cloud lockfile upload --json
The uploaded record includes checksum information, allowing the Cloud project to distinguish lockfile revisions and keep a history of dependency states.
\n
This is useful when several developers or environments build the same project. The lockfile remains in source control as before, while the Cloud record provides another view of which dependency state was associated with project activity.
\n
The command reports direct errors when the project has not been linked or when the requested lockfile does not exist.
\n
Build reports
\n
A local build can submit a report to Softadastra Cloud with:
\n
vix build --report
The build itself follows the normal Vix process. The CLI configures the project, invokes the selected build backend, and determines whether the requested targets succeeded.
\n
When the project is linked to Softadastra Cloud, Vix can then submit information such as:
\n
\n
build status;
\n
elapsed time;
\n
project identity;
\n
build configuration;
\n
relevant local project context.
\n
\n
The report is intended to describe the local build, not replace it.
\n
A report submission failure does not turn a successful native build into a failed build command. The CLI reports the Cloud error separately while preserving the successful build exit status.
\n
This is important for local work and CI. Cloud reporting is useful project metadata, but a temporary network or API failure should not make a valid compiled binary appear broken.
\n
Cloud package publishing
\n
Private package versions can be published to Softadastra Cloud through the existing publish command:
\n
vix publish --cloud
The equivalent Cloud command is:
\n
vix cloud publish
Cloud publication is explicit. Running vix publish without --cloud continues to use the public Vix Registry workflow.
\n
A private package publication can specify its identity and visibility:
The command can prepare the package archive, calculate its checksum, read metadata from vix.json or vix.app, create the Cloud package record, and upload the version archive.
\n
Duplicate package versions produce a clear conflict message instead of a generic API failure.
\n
The public and private package workflows therefore share the same high-level command while remaining separate destinations with different access models.
\n
Cloud diagnostics
\n
vix doctor --cloud now inspects the Cloud side of the development environment.
\n
The diagnostic includes:
\n
\n
API connectivity;
\n
authentication state;
\n
current project linkage;
\n
lockfile upload availability;
\n
build report support.
\n
\n
Cloud command failures also use more specific API errors for common cases such as missing authentication, missing project links, permission failures, missing files, and duplicate package versions.
\n
The Cloud HTTP client uses the existing vix::requests module instead of introducing a separate networking implementation inside the CLI.
\n
This keeps TLS, request handling, error conversion, and response parsing aligned with the networking code already maintained by Vix.
\n
Generated WebSocket modules
\n
The application module generator now supports WebSocket workflows.
The explicit --name option is useful in scripts and project generators where the module name is passed as a command option rather than a positional argument.
\n
Generated metadata records the selected workflow in the module’s vix.module file.
\n
WebSocket workflows
\n
The initial WebSocket generator provides four workflows:
\n
attached\nstandalone\nbridge\nclient
Each workflow represents a different relationship between the generated module and the application runtime.
\n
Attached
\n
An attached module participates in the application’s existing runtime.
\n
It is appropriate when the project already has a primary HTTP or backend application and the WebSocket feature should run as part of that process.
\n
The generated module contributes its WebSocket behavior without defining an unrelated second application entry point.
\n
Standalone
\n
A standalone module provides its own runtime-capable WebSocket application.
\n
This is useful for a service whose primary responsibility is WebSocket communication and which does not need to attach to another generated backend runtime.
\n
Bridge
\n
A bridge module is runtime-capable and is intended for workflows where WebSocket communication connects two parts of an application or forwards events between boundaries.
\n
The generated structure provides a dedicated place for that bridge logic while still participating in the Vix module and runtime system.
\n
Client
\n
A client module generates WebSocket client support code.
\n
Unlike the other workflows, it does not take ownership of application startup and must not be selected as the project runtime module.
\n
Vix now excludes these non-runtime client modules when deciding which generated module should participate in runtime generation.
\n
WebSocket runtime compatibility
\n
Earlier generated modules still referenced runtime symbols that no longer matched the current WebSocket API, including older forms such as:
\n
vix::websocket::Server\nvix::run_http_and_ws
This could produce a module that looked structurally correct but failed during the normal application build.
\n
The generator now uses the current WebSocket headers, runtime types, and startup model. Attached, standalone, and bridge modules can compile through the standard:
\n
vix build
workflow.
\n
Module registration and generated vix.app metadata were also updated so WebSocket contributions work in both application and backend projects.
\n
Backend WebSocket status panel
\n
Generated backend assets now include a small WebSocket connection status panel.
\n
After starting a generated backend:
\n
vix build\nvix run
the browser page attempts to connect to the configured local WebSocket endpoint and reports whether the connection is open, closed, or unavailable.
\n
The panel is not intended to replace application-specific WebSocket tooling. It provides immediate confirmation that the generated server, route, frontend asset, and browser connection agree on the basic runtime configuration.
\n
This is particularly useful after creating a backend project and adding an attached WebSocket module because the developer can verify the generated integration before writing application-specific events.
\n
API-only backend projects
\n
Backend project generation now supports an API-only mode:
\n
vix new api --template backend --api-only
The generated project keeps the production-oriented backend structure, including:
This mode is intended for applications where the C++ backend and frontend are deployed separately.
\n
The frontend may be built with Vue, React, Next.js, SvelteKit, another web framework, or a static hosting system. The Vix project remains responsible for API routes, application services, middleware, storage, and native runtime behavior.
\n
Static files, views, and related bootstrap code are now conditional parts of the standard backend template rather than assumptions shared by every backend project.
\n
Global package installation
\n
Vix now provides a user-space global installation workflow for C++ packages that expose libraries or command-line executables.
Global packages are installed into a Vix-managed prefix rather than /usr/local by default.
\n
This avoids requiring root access and gives Vix enough ownership information to update and remove package files safely.
\n
When the package provides standard CMake installation rules, Vix builds the package and uses those rules. Installed files are recorded in the package’s global installation metadata.
\n
Executables are exposed through the Vix global bin directory, making commands such as ovi available when that directory is present on PATH.
\n
Global installation ownership
\n
Global installation is more than copying a compiled binary.
\n
Vix records which package owns each installed file and checks for executable name conflicts before replacing an existing command.
\n
Uninstallation removes only files registered to the selected package.
\n
This prevents a package uninstall from deleting unrelated headers, libraries, or commands that happen to share the same installation prefix.
\n
Scoped forms are accepted consistently by install and uninstall commands, including package names such as:
\n
@rix/rix
Normal uninstall output is kept short and reports the result with elapsed time rather than printing every removed path. More detailed output can still be requested when needed.
\n
Packages with internal Vix targets
\n
Some packages are designed to build inside the Vix package environment and reference internal targets prepared by the normal Vix dependency pipeline.
\n
Treating those packages as unrelated standalone CMake projects can fail because their expected targets have not been created.
\n
Global installation now passes packages such as rix/rix through the Vix build and installation workflow instead of configuring their source directories in isolation.
\n
This preserves the same dependency preparation and target environment used when the package is consumed by a regular project.
\n
Git dependencies
\n
Vix projects can now install dependencies directly from Git repositories:
The CLI normalizes common Git URL forms and inspects the repository to determine how it can be consumed.
\n
When no revision is specified, Vix selects the latest stable Semantic Versioning tag when one can be determined. It then resolves the selected revision to an exact commit and records that commit in vix.lock.
\n
The source is materialized under:
\n
.vix/deps
and Vix generates:
\n
.vix/vix_deps.cmake
for normal build and run workflows.
\n
The first implementation supports CMake repositories and header-only repositories.
\n
Git dependency declarations
\n
A Git dependency recorded in vix.app can describe:
\n
\n
repository URL;
\n
tag;
\n
branch;
\n
commit;
\n
expected CMake target;
\n
CMake options;
\n
public include roots;
\n
source subdirectory;
\n
header-only behavior.
\n
\n
This allows the lockfile to preserve the exact resolved source while the application manifest describes how the project consumes it.
\n
The repository URL alone is often sufficient for common packages. Vix inspects the CMake project, searches for likely public targets, and prefers stable namespaced targets when the choice is unambiguous.
\n
For example, a repository may expose several internal targets but have one clear consumer target such as:
\n
fmt::fmt
When several plausible public targets remain and Vix cannot choose safely, installation stops with a direct ambiguity error instead of linking an arbitrary target.
\n
Automatic dependency preparation
\n
Dependencies declared in vix.app are prepared automatically by normal project commands.
\n
A single-file execution inside a project no longer requires a separate deprecated dependency preparation step before running:
\n
vix run main.cpp
When the file includes a project dependency, Vix resolves the dependency state, prepares the checkout, and selects the required compile path.
\n
The same generated dependency information is available to regular project builds.
\n
This brings dependency preparation into the commands that actually need the dependencies instead of requiring the developer to remember an independent synchronization command.
\n
Initializing an existing directory
\n
Vix.cpp v2.7.3 adds:
\n
vix init
The command turns the current directory into a minimal Vix project without generating a complete application template.
Vix derives a safe project name from the directory, detects existing C++ source files, and creates a minimal vix.app.
\n
Supported options include:
\n
--name\n--lib\n--standard\n--force
vix init is intended for existing source trees or small folders that already contain code.
\n
vix new remains the appropriate command when the developer wants a complete scaffold with a selected template, directory structure, examples, tests, and project documentation.
\n
Temporary dependencies for single-file runs
\n
A single C++ file can now use a Git dependency without permanently modifying the current directory:
\n
vix run main.cpp \\\n --dep https://github.com/fmtlib/fmt
Vix creates a temporary dependency environment, resolves the repository, prepares the required include or link information, compiles the file, and reuses the dependency cache where possible.
\n
This mode does not create:
\n
vix.app\nvix.lock\n.vix/
in the current directory unless the developer explicitly saves the dependency into a project.
\n
It is useful for evaluating a library, reproducing a small example, or testing an API before deciding whether the code belongs in a permanent Vix project.
\n
Faster single-file execution
\n
vix run <file.cpp> now selects its execution path from the file’s actual dependency requirements.
\n
A source file that uses only the C++ standard library can use the direct compiler path even when its parent project contains Git dependencies.
\n
Previously, the presence of:
\n
.vix/vix_deps.cmake
could force every single-file run through CMake, including files that did not use any dependency from that file.
\n
Vix now examines the source includes and the dependency metadata before deciding whether CMake is necessary.
\n
The general behavior is:
\n
standard library only direct compiler\nheader-only dependency direct compiler with include paths\ncompiled dependency CMake with vix::deps
This preserves the fast script-like workflow for simple programs while still supporting correct linking when a compiled package is required.
\n
Direct-run caching
\n
Repeated direct runs can reuse the compiled binary when the relevant inputs have not changed.
\n
The cache key considers:
\n
\n
source content;
\n
compiler;
\n
C++ standard;
\n
compiler flags;
\n
include directories;
\n
linked dependencies;
\n
resolved dependency commits.
\n
\n
A change to any of these inputs invalidates the cached executable.
\n
This is especially useful for small examples and temporary dependency experiments, where repeatedly invoking a full project configuration would add unnecessary delay.
\n
Public registry publishing
\n
The public vix publish workflow now validates the exact tagged source.
\n
Publishing a version should describe the immutable revision associated with that version, not whichever files happen to exist in the current working directory.
\n
Vix now creates a detached temporary checkout at the selected tag commit. It reads vix.json, scans public headers, and prepares registry metadata from that checkout.
\n
Local uncommitted changes, files added after the tag, or a branch that has moved beyond the release therefore cannot silently influence the published package description.
\n
The working tree remains untouched because inspection happens in the temporary checkout.
\n
Durable package identity
\n
A package’s registry identity is now tied to its normalized repository URL.
\n
When a repository already exists in the registry under a particular:
\n
namespace/name
future publications from the same repository must preserve that identity.
\n
Changing the package name in vix.json does not silently create a second registry package for the same repository.
\n
This prevents accidental renames from splitting versions, download history, search results, and ownership information across duplicate package entries.
\n
Repository identity mismatches are checked before remote tag validation so the developer receives the most relevant error first.
\n
Tag and remote validation
\n
Public publishing verifies that the requested version tag exists at the expected repository revision.
\n
Git network, authentication, and repository errors are now distinguished from a genuinely missing remote tag.
\n
Earlier behavior could report some remote access failures as though the tag had simply not been pushed. The updated validation preserves the underlying reason when the repository cannot be reached or accessed.
\n
This makes publication failures easier to diagnose, particularly for private remotes, incorrect repository URLs, or temporary network problems.
\n
Public header scanning
\n
The detached tagged checkout is also used to scan the package’s declared public include roots.
\n
Vix derives API metadata from the source that users will actually receive for that version.
\n
The generated metadata is deterministic: publishing the same immutable tag with the same manifest produces the same package API description.
\n
This creates a stable basis for registry browsing, documentation links, package analysis, and future compatibility tooling.
\n
Manifest metadata preservation
\n
The registry package type now comes from the real package manifest.
\n
Vix no longer forces published packages to appear as header-only when that does not match their actual build model.
\n
Missing license information is also left missing rather than silently replaced with MIT.
\n
Publication should preserve what the package declares and report invalid or incomplete metadata directly. It should not invent legal or technical properties on behalf of the author.
\n
Publish output
\n
Normal publishing output remains focused on the result.
\n
A dry run no longer prints the complete registry JSON automatically:
\n
vix publish --dry-run
Structured output remains available with:
\n
vix publish --dry-run --json
Detailed human-readable diagnostics can be requested with:
\n
vix publish --dry-run --verbose
This keeps routine publication readable while preserving the information needed for automation and investigation.
\n
Validation and regression coverage
\n
The release validates the new workflows across application generation, dependency management, Cloud commands, global installation, script execution, and public publishing.
\n
WebSocket coverage includes:
\n
\n
attached runtime modules;
\n
standalone runtime modules;
\n
bridge modules;
\n
client-only modules;
\n
custom names through --name;
\n
correct runtime selection;
\n
generated vix.module metadata;
\n
application and backend builds.
\n
\n
Backend template validation covers both the standard scaffold and API-only generation, including the absence of static frontend resources in API-only projects.
\n
Cloud validation covers authentication, project linking, status reporting, lockfile upload, build report submission, explicit Cloud publication, duplicate versions, missing links, missing files, and API errors.
\n
Package tests cover user-space global prefixes, executable exposure, package ownership, conflict detection, scoped uninstall names, and packages requiring the Vix build environment.
\n
Git dependency tests cover URL normalization, stable tag selection, exact commit locking, CMake projects, header-only projects, target detection, ambiguous targets, generated dependency CMake, and normal run preparation.
\n
Single-file run tests cover direct compilation, header-only include paths, compiled dependency fallback, temporary dependencies, and cache invalidation.
\n
Public publishing tests cover tagged source inspection, repository identity, remote tag validation, header scanning, deterministic API metadata, manifest package types, missing licenses, and output modes.
\n
Documentation
\n
The documentation was updated to cover the workflows introduced or corrected by this release.
\n
The application module documentation now explains WebSocket generation, workflow selection, custom names, module registration, and runtime participation.
\n
Backend template documentation covers the generated WebSocket status panel and the difference between the standard frontend-serving backend and --api-only.
\n
Cloud documentation covers login, project linking, status, lockfile upload, build reports, private package publication, and vix doctor --cloud.
\n
Package documentation covers global installations, executable commands, ownership-aware uninstallation, Git dependencies, target detection, lockfile behavior, and dependency caching.
\n
The CLI guides also document vix init, temporary vix run --dep experiments, and the stricter public publication requirements.
\n
Compatibility
\n
Existing public registry publication remains the default behavior of:
\n
vix publish
Private Cloud publication requires the explicit --cloud option.
\n
Existing backend templates continue to include frontend assets unless --api-only is selected.
\n
Projects without Git dependencies continue to build and run through their existing workflow. Git support adds another dependency source without replacing registry packages.
\n
Simple vix run scripts continue to use direct compilation where possible. Projects requiring compiled dependencies fall back to the generated CMake dependency environment automatically.
\n
Global installations use a Vix-managed user prefix by default, avoiding changes to system directories. Packages that provide correct CMake installation rules continue to use those rules.
\n
Cloud reporting remains optional. A project that is not authenticated or linked continues to build locally without requiring Softadastra Cloud.
\n
Known limitations
\n
The first Git dependency implementation supports CMake-based and header-only repositories. Projects that require another build system need explicit support in a later release or must provide a compatible CMake integration.
\n
Automatic target detection is used only when Vix can identify a clear public consumer target. Repositories exposing several equally plausible targets require the developer to specify the intended target.
\n
Temporary vix run --dep environments are intended for focused experiments. A dependency that becomes part of the application should be saved into vix.app so its exact resolution is recorded in the project lockfile.
\n
Softadastra Cloud in this release coordinates project metadata, private packages, lockfiles, and build reports. It does not perform remote C++ compilation.
\n
The generated WebSocket status panel checks connection availability only. Application authentication, reconnection policy, message protocols, and production frontend behavior remain the responsibility of the project.
\n
Release summary
\n
Vix.cpp v2.7.3 connects several workflows that previously required separate manual steps.
\n
WebSocket modules can be generated with an explicit runtime model and built through normal application and backend projects. Backend services can be created without bundled frontend assets when the interface is hosted separately.
\n
The CLI can authenticate with Softadastra Cloud, link local projects, upload dependency state, submit local build reports, and publish private package versions while keeping compilation on the developer’s machine.
\n
Git repositories can participate in project dependencies, temporary single-file experiments, and reproducible lockfiles. Command-line packages can be installed globally into a user-controlled Vix prefix with tracked ownership and clean uninstallation.
\n
Public registry publication now derives its metadata from the exact release tag and protects package identity across versions.
\n
Together, these changes make Vix more useful across the full path from a small C++ file to a modular backend project with shared package and project state.
\n';
+const v2_7_3 = {
+ html
+};
+export {
+ v2_7_3 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.4-C0ziq3Yh.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.4-C0ziq3Yh.js
new file mode 100644
index 000000000..eec1e2265
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.4-C0ziq3Yh.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.7.4
\n
Vix.cpp v2.7.4 makes specialized SDK profiles composable.
\n
A project can now use modules from several installed profiles, such as web and data, without installing the complete all SDK. Before configuring CMake, Vix examines the project’s vix::* dependencies, determines which installed profiles provide them, and prepares one coherent SDK package for the build.
\n
The release also improves the failure path when a project requests a known Vix module whose provider profile is not installed. Instead of allowing CMake to fail later with an unresolved target, the CLI identifies the missing module, reports its provider profile, and gives the exact installation command.
\n
Release focus
\n
SDK profiles were introduced to avoid requiring every developer to install the full Vix SDK.
\n
A backend application may need the web profile, a database-oriented tool may need data, and a desktop or game project may use another specialized profile. This keeps installations smaller and gives each project a more focused development environment.
\n
The original profile model worked well when a project remained inside one profile. The problem appeared when an application crossed that boundary.
\n
A Cloud service, for example, may use WebSocket support from web together with database functionality from data:
Installing both profiles did not solve the problem by itself. Each profile provided an independent CMake package named Vix, and CMake does not merge several packages returned by separate find_package(Vix) calls.
\n
Vix.cpp v2.7.4 addresses this at the CLI level. It treats installed profiles as components of one SDK environment and creates a local composed package when the project needs more than one of them.
\n
Composing installed SDK profiles
\n
The following workflow now supports a project that uses both web and data modules:
\n
vix upgrade --sdk web data\nvix install\nvix build --preset release
The project does not need the heavier all profile merely because it links modules from two specialized profiles.
\n
Before CMake configuration begins, vix build scans the project for known Vix targets. It resolves each requested module to the profile that provides it and verifies that the required profile is installed.
Because more than one provider is required, the CLI generates a composed SDK package inside the build directory and passes it to CMake through Vix_DIR.
\n
The project continues to use the normal public target names. SDK composition is an implementation detail handled by vix build.
\n
Why CMAKE_PREFIX_PATH was not enough
\n
Each installed SDK profile contains its own package configuration:
\n
VixConfig.cmake\nVixTargets.cmake
All profiles use the same CMake package name because they represent different installations of Vix rather than unrelated libraries.
\n
Adding the web and data installation roots to CMAKE_PREFIX_PATH does not cause CMake to combine their targets. find_package(Vix) selects one package location and loads the configuration found there.
\n
As a result, the first selected profile could expose vix::websocket while leaving vix::db unresolved, or expose vix::db while omitting vix::websocket.
\n
Vix now resolves the profiles before invoking CMake and presents them through one generated package. The composed configuration contains the targets required by the project while preserving the installation paths and exported properties of their original profiles.
\n
Automatic SDK profile selection
\n
Developers do not need to declare the required SDK profile separately in the build command.
\n
vix build scans the project’s CMake files and Vix manifests for known vix::* targets before configuration. It then maps those targets to the profiles that officially provide them.
When every requested module belongs to one profile, Vix uses that installed SDK directly.
\n
When the project requires modules from several profiles, Vix creates a composed package for that build.
\n
This keeps the SDK decision connected to the actual project dependencies. A project that starts with web and later adds vix::db can be built after installing data, without manually changing a separate SDK configuration file.
\n
Shared SDK profile metadata
\n
The CLI now uses one shared source of truth for SDK profile information.
\n
Previously, the metadata displayed by:
\n
vix upgrade --sdk info
and the metadata used internally by vix build could evolve through separate code paths. That created a risk that one command would describe a profile differently from the way another command resolved it.
\n
Profile names, provided modules, descriptions, and provider relationships now come from a shared CLI helper.
\n
This means the information shown to the developer and the information used during build resolution follow the same model.
\n
It also makes later profile changes easier to maintain because a module should not need to be registered independently in several commands.
\n
Exported SDK aliases
\n
Some public Vix targets are aliases in the source tree.
\n
During CMake export, aliases are not installed as ordinary targets. The underlying implementation target is exported, but the public alias used by consumer projects may need to be recreated in VixConfig.cmake.
\n
Vix.cpp v2.7.4 restores the missing public aliases for:
This ensures that installed SDK consumers can use the same public target names that are available inside the Vix source tree.
\n
The composed SDK generator preserves these aliases as well, so projects behave consistently whether they use one profile directly or several profiles through a generated composition.
\n
Imported target paths
\n
CMake export files commonly describe installed paths relative to an internal variable named _IMPORT_PREFIX.
That variable normally points to the root of the SDK installation that owns the target.
\n
When a target from a secondary profile is copied into a composed configuration, leaving _IMPORT_PREFIX unresolved or binding it to the composed package directory can produce invalid paths such as:
\n
/include\n/lib/libvix_websocket.a
Vix now rewrites every _IMPORT_PREFIX occurrence to the installation root of the source profile before adding the target to the composed package.
\n
A target imported from web therefore continues to resolve its headers and libraries from the installed web SDK, while a target imported from data resolves against the data installation.
\n
This applies to all occurrences in the exported target definition, not only the first path encountered.
\n
Project-generated targets
\n
Not every target using the vix:: namespace represents an installed SDK module.
\n
Vix can generate project-specific helper targets such as:
\n
vix::deps
These targets describe the current project’s resolved dependencies and are created during project generation. They are not modules provided by an installed SDK profile.
\n
The SDK resolver now excludes these generated targets when scanning project files.
\n
Without this distinction, vix build could report that a profile was missing for a target that no profile was ever supposed to provide.
\n
The resolver therefore considers only known public SDK modules when deciding which profiles are required.
\n
Missing SDK diagnostics
\n
When a project requests a known Vix module whose provider profile is not installed, the CLI now reports the problem before CMake configuration.
Target "app" links to:\n vix::websocket\nbut the target was not found.
The CMake message identifies the unresolved target but does not know which Vix SDK profile provides it or how the developer should install that profile.
\n
The new diagnostic keeps the failure at the level where it can be explained accurately.
\n
Incompatible profile versions
\n
Installed profiles used in the same composed SDK must come from the same Vix version.
\n
For example, Vix will not compose a web profile from one release with a data profile from another release merely because both contain valid CMake packages.
\n
Targets from different releases may have incompatible dependencies, export layouts, compile definitions, or module interfaces. Combining them could create a package that configures successfully but fails later in less predictable ways.
\n
Vix checks the installed profile versions before generating the composed SDK. When the versions differ, the build stops and reports the incompatibility.
\n
The developer can then upgrade the required profiles to the same Vix release before rebuilding.
\n
Vix does not generate a partial package or silently choose one version over another.
\n
Installation order independence
\n
SDK composition does not depend on the order in which profiles were installed.
\n
These installation sequences must describe the same environment:
\n
vix upgrade --sdk web\nvix upgrade --sdk data
and:
\n
vix upgrade --sdk data\nvix upgrade --sdk web
Provider selection is based on shared profile metadata and project requirements rather than directory discovery order.
\n
This matters because SDK installations may be accumulated over time. A developer should not need to remember which profile was installed first or reinstall profiles in a particular sequence to obtain a valid composed package.
\n
Choosing between profiles and all
\n
The all profile remains useful when a developer intentionally wants the complete Vix SDK available in one installation.
\n
It can be appropriate for SDK development, broad experimentation, release validation, examples that cover many unrelated modules, or environments where installation size is not a concern.
\n
Projects with focused requirements no longer need all merely to cross one profile boundary.
\n
A service using vix::websocket and vix::db can install web and data. A project using only web modules can continue to install web alone.
\n
The choice is therefore based on the project’s real module requirements rather than a limitation of the package configuration system.
\n
Regression coverage
\n
Vix.cpp v2.7.4 adds tests for direct and composed SDK usage.
\n
Web profile coverage includes projects using:
\n
vix::websocket\nvix::requests\nvix::middleware
Data profile coverage includes:
\n
vix::db\nvix::orm\nvix::cache\nvix::kv
Combined profile coverage includes a project linking both:
\n
vix::db\nvix::websocket
The test suite also covers:
\n
\n
separate profile installation state;
\n
profile installation order independence;
\n
automatic module-to-profile resolution;
\n
generation of the composed VixConfig.cmake;
\n
restoration of exported public aliases;
\n
_IMPORT_PREFIX rewriting;
\n
exclusion of project-generated targets;
\n
missing provider diagnostics;
\n
incompatible installed profile versions;
\n
suppression of the generic unresolved-target failure for known Vix modules.
\n
\n
These tests verify both successful composition and the cases where Vix must stop before invoking CMake.
\n
Documentation
\n
The CLI documentation now explains how installed SDK profiles participate in builds.
\n
It covers:
\n
\n
installing more than one specialized profile;
\n
automatic selection from project vix::* targets;
\n
composition of multiple installed profiles;
\n
version compatibility requirements;
\n
missing-module diagnostics;
\n
provider profile resolution;
\n
the role of the all profile.
\n
\n
The documentation also clarifies that installing several SDK roots is not enough for CMake to merge them automatically. Composition is performed by vix build because the CLI has the project context and profile metadata required to build one valid package configuration.
\n
Compatibility
\n
Projects using one SDK profile continue to use that profile directly.
\n
Existing project CMake files do not need to declare profile names. They continue to link public targets such as:
Projects that already use the all SDK remain compatible.
\n
Projects using modules from several specialized profiles can now install only the profiles they need. Their installed profiles must come from the same Vix version.
\n
The generated composed SDK is local to the build directory. It does not modify the installed profile packages or merge their files permanently on disk.
\n
Release summary
\n
Vix.cpp v2.7.4 turns specialized SDK profiles into a composable installation model.
\n
Projects can combine web, data, and other supported profile modules while keeping their SDK installation focused. vix build discovers the required modules from the project, resolves their provider profiles, verifies version compatibility, and generates one CMake package when composition is needed.
\n
The release also restores missing public aliases, preserves imported target paths across profile boundaries, ignores project-generated helper targets, and replaces generic CMake failures with diagnostics that identify the missing module and its provider.
\n
This makes SDK profiles practical for projects that do not fit entirely inside one category without forcing every developer to install the full Vix SDK.
\n';
+const v2_7_4 = {
+ html
+};
+export {
+ v2_7_4 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.5-Cz6YsC1I.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.5-Cz6YsC1I.js
new file mode 100644
index 000000000..6e3caccf8
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.5-Cz6YsC1I.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.7.5
\n
Vix.cpp v2.7.5 fixes two problems that affected existing projects rather than introducing a new developer-facing feature.
\n
The first concerns composed SDK installations. When several SDK profiles such as web and data were installed together, generated CMake targets could select the wrong provider or inherit properties from an unrelated module.
\n
The second concerns projects with lockfiles created before the current package integrity format. vix install can now migrate those old entries to the canonical vix-package-sha256 v2 format when the package identity, registry state, and local checkout prove that the migration is safe.
\n
These fixes are especially important for long-lived projects. A toolchain upgrade should not require developers to rebuild their dependency state manually when Vix already has enough information to verify and repair it.
\n
Release focus
\n
Vix SDK profiles allow developers to install only the parts of the platform required by a project.
\n
A web application may use the web profile, while a project that also needs database support may compose web and data. The generated SDK must then expose one coherent set of CMake targets, even when several profiles contain related modules or depend on overlapping parts of Vix.
\n
Before v2.7.5, some composed installations could generate aliases from the wrong profile or copy target properties from a target that was not the actual provider. These mistakes were difficult to notice during installation because the generated SDK remained structurally valid. They appeared later as incorrect includes, link libraries, compile definitions, or consumer build failures.
\n
Old lockfiles presented a different compatibility problem. Earlier versions of Vix stored package integrity information in formats that are no longer used. A project could have the correct package version and checkout but still fail installation because the stored hash metadata did not match the current canonical representation.
\n
Vix.cpp v2.7.5 addresses both cases by making SDK composition provider-aware and making integrity migration evidence-based.
\n
Composed SDK profiles
\n
SDK profiles are generated independently and can then be combined into a single installation.
\n
For example:
\n
vix upgrade --sdk web,data
A composed SDK must determine which profile officially provides each exported module. It cannot assume that every profile mentioning a dependency owns the corresponding target.
\n
Vix now creates aliases only for modules actually exported by the profile being processed. A profile no longer creates placeholder or duplicate aliases for modules that belong to another provider.
\n
This keeps the generated CMake namespace aligned with the real SDK exports and avoids ambiguous ownership when profiles overlap.
\n
Provider-aware target resolution
\n
The validation module exposed one of the composition errors fixed in this release.
\n
Both web-oriented and data-oriented parts of the SDK can depend on validation behavior, but that does not mean both profiles should provide the public vix::validation target.
\n
In a composed web + data installation, vix::validation is now resolved from its official web provider. The data profile no longer shadows that target merely because one of its modules depends on validation.
\n
This distinction between using a module and providing its exported target is important. Dependencies describe what a profile needs internally, while exports define what the profile owns and presents to consumer projects.
\n
By preserving that boundary, composed SDKs behave like the individual profiles from which they were built.
\n
Exact target property preservation
\n
Composed targets now preserve the exact exported properties of their provider SDK target.
The composition step reads them from the selected provider and applies them to the corresponding composed target without reconstructing the dependency graph from unrelated profile data.
\n
This matters because exported CMake targets are more than names. Their interface properties describe how consumer projects compile and link against the SDK.
\n
A composed target that points to the right module but carries the wrong interface properties is still incorrect.
\n
Target property isolation
\n
This release also fixes how target properties are extracted during SDK generation.
\n
The previous extraction logic could continue reading beyond the intended target boundary. In that situation, properties belonging to a later target could be associated with the target currently being generated.
\n
For example, properties from:
\n
vix::db
could leak into:
\n
vix::websocket
The generated file could therefore look valid while giving vix::websocket database-related libraries, include directories, or compile definitions that were never part of its official export.
\n
Property extraction is now isolated to the exact target being processed. Reading stops at the target boundary, and unrelated definitions cannot be carried into another composed target.
\n
This makes composed SDK output deterministic and equivalent to the provider SDK exports.
\n
Old lockfile integrity metadata
\n
Vix lockfiles record the exact package version and source state selected for a project.
\n
Modern lockfiles use canonical package integrity metadata based on:
\n
vix-package-sha256\nhash version 2
Projects created with older Vix releases may contain hashes calculated or represented using obsolete metadata. Even when the registry package and local checkout are correct, the old hash cannot be compared directly with the current canonical format.
\n
Previously, resolving this situation could require a manual sequence such as:
\n
vix registry sync\nvix update\nvix install
That workflow was inconvenient and could change more project state than necessary. The real requirement was not to resolve new versions, but to verify the already locked package and rewrite only its integrity metadata.
\n
Vix.cpp v2.7.5 performs that migration during vix install when all required safety conditions are satisfied.
\n
Canonical integrity migration
\n
When vix install encounters obsolete package integrity metadata, it verifies the complete identity of the locked dependency before modifying the lockfile.
\n
A successful migration updates only:
\n
hash\nhash_algorithm\nhash_version
The locked package id, selected version, tag, commit, source, and dependency resolution remain unchanged.
\n
This is intentionally narrower than vix update. The command does not search for a newer package or recompute the dependency graph. It confirms the package already selected by the lockfile and replaces only integrity fields that belong to the old format.
\n
After migration, subsequent vix install runs use the canonical v2 metadata normally.
\n
Automatic registry synchronization
\n
Integrity migration may require registry metadata that is not available in the local registry checkout.
\n
When that happens, vix install now synchronizes the registry internally and retries the verification. The user does not need to stop the installation and run a separate vix registry sync command.
\n
This synchronization is performed only when it is required to validate the locked package. It does not turn installation into a general package update.
\n
The workflow becomes:
\n
vix install
Vix determines whether the existing lockfile is current, whether registry information is needed, and whether the old integrity metadata can be migrated safely.
\n
This keeps installation responsible for making the locked project installable without silently changing the versions selected by that lockfile.
\n
Migration safety
\n
Automatic migration is allowed only when every available source of package identity agrees.
\n
Vix verifies that:
\n
\n
the locked package id matches the registry package;
\n
the locked version matches the registry version;
\n
the recorded tag matches;
\n
the recorded commit matches;
\n
the registry metadata describes the same package source;
\n
the local checkout corresponds to the locked package;
\n
the checkout contains the expected package content;
\n
the checkout is clean.
\n
\n
Only after these checks succeed does Vix calculate the canonical v2 package hash and update the integrity fields.
\n
This approach treats the old hash as obsolete metadata, not as permission to trust arbitrary local content. The migration is based on package identity, repository state, and registry evidence.
\n
Cases that still fail
\n
vix install continues to fail without rewriting the lockfile when the dependency state cannot be proven safe.
\n
A dirty checkout is rejected because local modifications mean the package content no longer corresponds exactly to the locked source.
\n
A registry commit mismatch is also rejected. Even when the package id and version appear correct, a different commit represents different source content and cannot be repaired through a hash metadata migration.
\n
Incomplete checkouts are rejected because Vix cannot calculate a trustworthy canonical package hash when expected files are missing.
\n
Modern v2 hashes are never treated as migration candidates. When a lockfile already declares vix-package-sha256 v2 and its hash is incorrect, installation fails normally. Vix does not replace a current-format hash merely because the local checkout produces a different result.
\n
This distinction is central to the safety model:
\n
obsolete format + verified identity = migrate\nmodern format + incorrect hash = fail
Automatic migration repairs compatibility metadata. It does not weaken integrity validation.
\n
Idempotent lockfile behavior
\n
After a successful migration, running vix install again does not modify the lockfile.
\n
The package now contains canonical integrity fields, so the normal verification path can compare the stored v2 hash directly with the installed content.
\n
This idempotence matters for source control and automated builds. A project should not produce repeated lockfile changes every time dependencies are installed.
\n
It also makes the migration easy to review. The first compatible installation produces a small, focused change to the integrity fields, and later installations leave the file untouched.
\n
Softadastra Cloud validation
\n
The migration was validated against Softadastra Cloud as a real consumer project.
\n
The project dependencies were installed with:
\n
vix install
No manual registry synchronization or dependency update was required.
\n
The project was then built with:
\n
vix build --preset release
The release build completed successfully and produced:
\n
bin/cloud
This validation covered a project using multiple Vix modules and a composed SDK rather than an isolated package fixture.
\n
It confirmed that an existing lockfile could be migrated during normal installation and then used to build the application without changing its selected dependency versions.
\n
Regression coverage
\n
Vix.cpp v2.7.5 adds regression tests for the SDK composition and lockfile migration paths.
\n
The SDK tests cover:
\n
\n
aliases generated only by the correct provider profile;
\n
vix::validation resolution in a web + data installation;
\n
preservation of provider target properties;
\n
isolation between unrelated target property blocks;
\n
prevention of vix::db properties leaking into vix::websocket.
\n
\n
The package integrity tests cover:
\n
\n
registry-backed migration from obsolete hash metadata;
\n
automatic registry synchronization;
\n
canonical v2 metadata generation;
\n
lockfile idempotence after migration;
\n
rejection of dirty local checkouts;
\n
rejection of registry commit mismatches;
\n
rejection of incomplete checkout state;
\n
rejection of incorrect modern v2 hashes.
\n
\n
These tests focus on the boundaries where an automatic repair must stop and return an error.
\n
Compatibility
\n
Projects using a single SDK profile continue to use the same public CMake targets.
\n
Projects combining profiles such as web and data should receive more accurate target aliases and interface properties without changing their CMakeLists.txt.
\n
Existing lockfiles using current vix-package-sha256 v2 metadata are not migrated. They continue through the normal integrity verification path.
\n
Old lockfiles are updated only when Vix can prove that the package identity and local checkout match the locked dependency. The selected versions, tags, commits, and package ids remain unchanged.
\n
Projects with intentionally modified dependency checkouts must clean, restore, or explicitly update those dependencies before installation can continue.
\n
Release summary
\n
Vix.cpp v2.7.5 improves the reliability of existing Vix projects in two areas where generated metadata must be exact.
\n
Composed SDKs now preserve module ownership and target properties across multiple profiles. Public aliases come from the correct provider, and one target can no longer inherit CMake properties from another.
\n
Old package integrity metadata can now be migrated during vix install without requiring a manual registry sync or a full dependency update. The migration changes only obsolete hash fields and proceeds only when the registry, lockfile, and local checkout all describe the same package state.
\n
The result is a more predictable SDK for multi-profile projects and a safer upgrade path for projects created with earlier Vix lockfile formats.
\n';
+const v2_7_5 = {
+ html
+};
+export {
+ v2_7_5 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.6-BpNHKudG.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.6-BpNHKudG.js
new file mode 100644
index 000000000..029c311c5
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.6-BpNHKudG.js
@@ -0,0 +1,132 @@
+const html = `
+
Vix.cpp v2.7.6
+
Vix.cpp v2.7.6 introduces a browser-based authentication flow for Softadastra Cloud.
+
Developers can now sign in through the Cloud website when running vix login, while the CLI receives the resulting session securely through a temporary local callback. The existing email and password flow remains available for scripts, remote environments, and cases where opening a browser is not practical.
+
This release also fixes the Cloud API endpoint used by the CLI and resolves an HTTPS transport lifetime problem that could cause valid Cloud requests to fail with misleading memory-allocation errors.
+
Release focus
+
The first Softadastra Cloud integration allowed the Vix CLI to authenticate using an email address and password entered directly in the terminal. That workflow was useful as an initial implementation, but it was not the right default for an interactive developer tool.
+
Terminal authentication requires the CLI to collect account credentials directly, offers limited room for future authentication methods, and separates the login experience from the Cloud website where account and workspace activity already takes place.
+
Vix.cpp v2.7.6 adds a browser flow designed around a short-lived authorization code. The user authenticates on cloud.softadastra.com, while the CLI waits on a temporary local callback server and exchanges the returned code with the Cloud API.
+
The final session continues to use the same local configuration format as the previous login implementation. The change is therefore focused on how a session is obtained rather than how authenticated commands store or consume it.
+
Starting a Cloud session
+
Running:
+
vix login
now presents two authentication methods:
+
1. Open browser
+2. Enter email and password
The browser option is intended for normal interactive use. The manual option preserves the existing terminal workflow and remains useful on headless machines, through SSH sessions, and in environments where opening a local browser is unavailable.
This keeps existing scripts and automation compatible while allowing the interactive command to use the safer browser experience by default.
+
Browser authentication flow
+
When browser login is selected, the CLI starts a temporary HTTP server on an available 127.0.0.1 port.
+
It then generates a cryptographically secure state value and opens the Softadastra Cloud login page with the callback address and state attached to the authorization request.
+
The browser handles the account authentication on the Cloud domain. After the user signs in, the Cloud backend creates a short-lived authorization code and sends it to the local callback address together with the original state value.
+
The CLI verifies that the returned state matches the value generated at the beginning of the flow. It then sends the authorization code to the Cloud API, which exchanges it for the final authenticated session.
+
The resulting session is stored in:
+
~/.vix/cloud/config.json
This is the same configuration location and session format used by manual login, so commands such as vix cloud status, package publication, lockfile upload, and build reporting do not need a separate authentication path.
+
Authorization code security
+
The browser never receives the final CLI session token in a redirect URL.
+
Instead, Softadastra Cloud creates a temporary authorization code that is bound to the current authentication flow. The code is associated with:
+
+
the generated state value;
+
the local redirect URI;
+
the authenticated Cloud user session;
+
a short expiration period.
+
+
Authorization codes are stored in hashed form, expire quickly, and can be exchanged only once.
+
This prevents a code copied from browser history or intercepted after a successful exchange from being reused to create another CLI session. Binding the code to the redirect URI and state also prevents it from being moved into an unrelated authentication attempt.
+
The final session token is returned directly to the CLI during the code exchange. It is not exposed in the browser address bar or passed through the local callback URL.
+
Cloud login page
+
Softadastra Cloud now provides a dedicated frontend route for CLI authentication:
+
/cli/login
The page receives the callback information generated by vix login, authenticates the user through the normal Cloud session, and requests a temporary CLI authorization code from the backend.
+
The callback is sent to the local CLI server in the background. The main browser tab remains on cloud.softadastra.com and transitions to a success state instead of navigating visibly to a temporary 127.0.0.1 page.
+
This avoids leaving the user on a local address that becomes unavailable as soon as the CLI closes its callback server.
+
The local callback response also uses a Softadastra Cloud confirmation page with animated status feedback. It clearly reports whether the callback was received, rejected, or could not be completed, while the primary browser tab remains on the Cloud site.
+
State validation
+
The state value connects the browser response to the CLI process that initiated the login.
+
A newly generated state is included when the CLI opens the Cloud login page. The same value must return through the local callback and must also match the authorization code record stored by the backend.
+
The CLI rejects the callback when the state is missing or does not match.
+
This validation protects the local callback server from accepting an unrelated browser request and prevents one login attempt from completing another process's authentication flow.
+
The callback server listens only on 127.0.0.1, so it is not exposed as a network service to other machines.
+
Manual login compatibility
+
Browser authentication does not remove terminal login.
+
The existing email and password request remains available through the interactive menu and through explicit command-line options. This provides a fallback when browser opening fails or when the developer is using an environment without a graphical session.
+
Manual login continues to return the same Cloud session structure and writes it to the same configuration file as browser login.
+
Machine-readable behavior is also preserved. When --json is used with the manual or scripted flow, the CLI does not mix interactive prompts, browser status messages, or decorative output into the JSON response.
+
This is important for tools that parse authentication failures or call vix login as part of a controlled setup process.
+
Cloud API endpoint
+
The Vix CLI now sends Cloud API requests to:
+
https://api.softadastra.com
Earlier builds could target the public frontend domain rather than the backend API domain. That made authentication and Cloud commands dependent on frontend routing behavior and could cause requests to reach the wrong service.
+
The frontend and API now have clear roles:
+
cloud.softadastra.com browser interface
+api.softadastra.com CLI and backend API
The browser login page remains on the frontend domain, while authorization code creation, exchange, session validation, workspace queries, and other Cloud operations use the API domain.
+
HTTPS transport fix
+
This release fixes an HTTPS transport lifetime problem that could appear during Cloud requests as:
+
network_error: std::bad_alloc
The error suggested that the application had exhausted memory, but the underlying problem was related to the lifetime of state used by the asynchronous HTTPS operation.
+
Transport objects and response buffers now remain valid until their associated callbacks and request operations have completed. Cloud requests therefore no longer access state that has already been destroyed or moved out of scope.
+
This correction applies to the shared HTTPS transport used by the CLI, not only to the browser login exchange.
+
Response-size limit
+
HTTPS transport now enforces a response-size guard.
+
Without an explicit limit, a malformed server, unexpected endpoint, or unbounded response could cause the client to continue growing its response buffer. The new guard stops buffering when the configured maximum is exceeded and returns a controlled transport error.
+
Cloud API responses are expected to remain small and structured, so an unusually large response is more likely to indicate an incorrect endpoint or server-side problem than a valid CLI result.
+
The guard makes this failure mode explicit rather than allowing response memory usage to grow without a boundary.
+
Login result
+
After a successful browser or manual login, the CLI reports the authenticated account and Cloud API address:
Cloud commands use the saved session automatically until it expires, becomes invalid, or is replaced by another login.
+
Error handling
+
The authentication flow distinguishes between browser, local callback, API, and session failures.
+
A rejected or expired authorization code produces an authentication error rather than a generic network failure. A state mismatch is rejected before the code exchange is attempted. When the backend is unavailable, the CLI reports that the Cloud service could not be reached instead of treating the request as invalid credentials.
+
Manual login errors remain compatible with JSON output:
This allows scripts to inspect the structured error without removing the browser-oriented experience from normal interactive use.
+
Cloud backend support
+
Softadastra Cloud now includes the backend endpoints and persistence needed for CLI authorization codes.
+
The backend creates a temporary code only after confirming that the browser has an authenticated Cloud session. It records the code hash, user identity, state, redirect URI, and expiration time.
+
During exchange, the backend verifies each of those properties before creating the final CLI session. A successful exchange consumes the code immediately.
+
The authorization code is not a second long-lived session. It exists only to transfer authenticated browser intent back to the CLI without exposing the final token through browser navigation.
+
Validation
+
The Vix umbrella project was built with the database configurations used by the Cloud integration:
Browser login was verified through the complete flow: local callback startup, browser authentication, state validation, authorization code creation, one-time exchange, session storage, and authenticated Cloud status.
+
The manual email and password fallback was also tested to confirm that the previous terminal workflow remains functional.
+
Validation additionally covered:
+
+
clean JSON errors from manual login;
+
vix cloud status after browser authentication;
+
Cloud API requests through api.softadastra.com;
+
backend-unavailable diagnostics;
+
expired or invalid authorization codes;
+
state mismatch rejection;
+
single-use authorization code behavior;
+
session persistence in ~/.vix/cloud/config.json.
+
+
Compatibility
+
Existing authenticated Cloud sessions remain compatible because v2.7.6 does not change the local session configuration format.
+
Scripts using vix login --email and --password can continue to use the terminal flow. Commands using --json retain machine-readable output without browser-oriented formatting.
+
The main behavior change affects interactive vix login, which now offers browser authentication before manual credential entry.
+
Cloud commands now use the API domain rather than the public frontend domain. Custom development environments that override the Cloud address should ensure that their configured URL points to an API-compatible backend.
+
Known limitations
+
Browser authentication requires the CLI to open or provide a URL that can be accessed in a browser on the same machine.
+
The callback uses a temporary 127.0.0.1 HTTP server rather than a registered operating-system URL scheme. This keeps the first implementation portable and independent of desktop registration, but it requires the browser to be able to reach the local machine where vix login is running.
+
Remote SSH environments may not be able to use the callback directly when the browser runs on another computer. Manual email and password login remains available for those cases.
+
The authentication system currently supports the existing Softadastra Cloud account session. Additional identity providers, device authorization, organization-enforced authentication policies, and passkey-specific CLI flows are not part of this release.
+
Release summary
+
Vix.cpp v2.7.6 makes Cloud authentication fit more naturally into the developer workflow.
+
Interactive users can authenticate through the Softadastra Cloud website without placing their password directly into a CLI prompt. The browser receives only a temporary authorization code, the CLI validates the login state, and the final session is exchanged directly with the API.
+
Manual authentication remains available where it is needed, and both methods produce the same local session used by existing Cloud commands.
+
The release also corrects the API endpoint used by the CLI and strengthens the shared HTTPS transport so Cloud requests have predictable object lifetimes and bounded response buffering.
+`;
+const v2_7_6 = {
+ html
+};
+export {
+ v2_7_6 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.7-DoWGBtPN.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.7-DoWGBtPN.js
new file mode 100644
index 000000000..82ceeeeaf
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.7-DoWGBtPN.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.7.7
\n
Vix.cpp v2.7.7 introduces the first package-based extension architecture for Vix Note.
\n
The release allows Note to discover new cell types and runtimes from ordinary Vix packages rather than requiring every integration to be implemented directly inside the Note module. It also adds the registry, command-line, and interface workflows needed to install and manage those extensions.
\n
Alongside the Note work, this release modernizes the Vix Reply interactive terminal. Native C++ snippet mode now behaves more like a real code editor, with syntax highlighting, automatic indentation, cursor-aware editing, additional keyboard shortcuts, and an initial optional Vi keymap.
\n
The release also fixes global installation for header-only packages that build command-line executables without declaring CMake runtime installation rules.
\n
Release focus
\n
Vix Note already supported Markdown, HTML, C++, and Reply cells, but those cell types were part of the application itself. Adding another language or specialized runtime required modifying the Note codebase, rebuilding the application, and maintaining the integration as part of the main project.
\n
Vix.cpp v2.7.7 changes that boundary.
\n
A Note extension can now be published as a standard package through the Vix Registry. The package declares its Note contribution in its manifest, provides the required runtime when execution is needed, and becomes discoverable after installation. This gives extension authors a path to add languages, visualization tools, development utilities, and domain-specific cells without placing every integration inside Vix Note.
\n
The goal of the initial system is not to define every possible extension mechanism at once. It establishes the package format, discovery rules, execution protocol, management workflow, and compatibility model that later releases can extend.
\n
Package-based Vix Note extensions
\n
Vix packages can now declare a Note extension through the extensions.note manifest section.
\n
The extension metadata describes how the package participates in Vix Note. It can declare an extension API version, capabilities, contributed cell types, runtime configuration, aliases, and required permissions. This information remains part of the package when it is published, installed, and recorded in the global package registry.
\n
Using the existing package system is an important part of the design. Extension authors do not need a separate distribution service or an unrelated installation format. A Note extension follows the same namespace, versioning, registry, publication, and installation model as other Vix packages.
\n
This also means the extension lifecycle fits into an existing Vix workflow: developers can search for packages, inspect their metadata, install them globally, and remove them using familiar commands.
\n
Extension discovery
\n
Vix Note now discovers extensions from three sources:
\n
\n
built-in extensions shipped with Vix Note;
\n
project-local extensions;
\n
globally installed Vix packages.
\n
\n
Project-local extensions take precedence over global extensions with the same contribution. This makes it possible for a project to select or develop a specific integration without changing the global environment used by other projects.
\n
Built-in cell types remain protected. An installed package cannot silently replace the standard Markdown, HTML, C++, or Reply behavior by declaring the same type. This keeps the default Note environment predictable while still allowing external packages to add new cell types and capabilities.
\n
The existing built-in cells now pass through the same extension system used by external integrations. This avoids maintaining two unrelated execution paths and ensures that the extension architecture is exercised by the standard Note workflow itself.
\n
To inspect the extensions currently visible to Vix Note, use:
\n
vix note --list-extensions
The command includes built-in, project-local, and globally installed extensions after applying the normal discovery and precedence rules.
\n
Custom cell types
\n
The .vixnote document model can now preserve cell types that are not built into the application.
\n
For example, a document containing a python cell can be loaded, saved, and exported without Vix Note rewriting the cell as an unknown built-in type or discarding its original contribution metadata. The cell remains part of the document even when its extension runtime is not currently available.
\n
This distinction matters for portable notebooks. Opening a document on a machine without one of its extensions should not damage the document. Execution may be unavailable until the required package is installed, but the notebook structure and source content remain intact.
\n
Preserving external cell types also allows documents to move between projects and machines while retaining the information needed to restore their original execution environment.
\n
External runtime protocol
\n
Executable Note extensions can communicate with Vix Note through the vix-note-extension-1 JSON protocol.
\n
The initial implementation uses a generic external runtime. Vix Note starts the configured extension process, sends a structured execution request, and reads the structured response produced by that process. The request can include information such as the cell identifier, cell type, source code, execution count, working directory, document path, extension identity, and extension version.
\n
Keeping the protocol language-independent allows an extension runtime to be implemented with the language or toolchain that fits its purpose. The package remains a Vix package, while the process behind the extension can execute Python, invoke a compiler, communicate with another runtime, or transform the cell content.
\n
The current runtime model is intentionally simple: each execution starts a one-shot process. This provides a clear isolation boundary and is sufficient for the first external integrations. Persistent kernels and long-running extension sessions require additional lifecycle and protocol work and are not part of this release.
\n
Dynamic cell discovery
\n
Vix Note now exposes discovered extensions through:
\n
GET /api/extensions
The Note frontend uses this endpoint to determine which cell types are currently available. New cell types no longer need to be duplicated in a static frontend list before they can appear in the interface.
\n
The endpoint provides the contribution metadata required by the editor, including the available types and their associated extension information. The frontend can therefore adapt to the current environment after an extension is installed, enabled, disabled, or removed.
\n
This is also the foundation for future extension-aware editor behavior. A later extension may need more than a name in the cell selector, but dynamic discovery must exist before richer contributions can be introduced cleanly.
\n
Extension management in Vix Note
\n
Vix Note now includes an extension management interface.
\n
The interface separates built-in, installed, recommended, and registry extensions so developers can understand where a contribution comes from and whether it is already available in the current environment. An extension can be installed, uninstalled, enabled, or disabled without leaving Note.
\n
Each extension also has a details page containing its runtime information and contribution metadata. This provides a place to inspect the cell types, capabilities, aliases, and execution configuration associated with a package before using it in a document.
\n
Disabling an extension keeps the package installed while removing its contributions from the active Note environment. Uninstalling removes the installed package and its registered extension metadata. These are intentionally separate operations because temporarily disabling an integration should not require downloading it again later.
\n
Registry and package commands
\n
The package publication workflow now understands Note extension metadata.
\n
When vix publish processes a package containing an extensions.note section, it validates the extension declaration and preserves the metadata in the published package entry. Invalid extension declarations are rejected before they become part of the registry.
\n
vix search also supports extension-specific filters:
\n
vix search --extension note --json
Available options include:
\n
--extension\n--capability\n--type\n--json
Extension searches do not require a text query. A developer can search by contribution type or capability when the package name is not known.
\n
Ordinary text search continues to work:
\n
vix search json --json
Global package installation now preserves extension metadata in the global installation registry. This allows Vix Note to discover an installed extension without needing to inspect or reinterpret every package directory on each startup.
\n
Together, these changes connect the complete workflow: publication records the contribution, search exposes it, installation preserves it, and Vix Note discovers it.
\n
Vix Reply editor
\n
Vix Reply receives a substantial interactive terminal update in v2.7.7.
\n
The terminal now opens with a Vix-branded banner that identifies the Reply version, compiler, platform, exit shortcut, clear shortcut, and help command. Native C++ snippet mode has its own prompt so it is visually distinct from the regular Reply session.
\n
The most significant changes are inside the C++ editor. Earlier versions were primarily designed for appending text to the end of a line. The updated editor maintains an active cursor position and can insert or delete content in the middle of existing code.
\n
Left and right arrow keys now move across the complete input line. Home and End move to the beginning or end, while Delete removes the character at the cursor. Common terminal editing shortcuts are also supported:
\n
Ctrl+A move to the beginning\nCtrl+E move to the end\nCtrl+U remove content before the cursor\nCtrl+K remove content after the cursor
These operations continue to work while syntax highlighting is active.
\n
C++ syntax highlighting
\n
Native C++ snippet mode now applies real-time lexical highlighting while code is entered.
\n
The highlighter recognizes common C++ structures including preprocessor directives, included headers, keywords, built-in types, strings, numeric literals, comments, namespaces, macros, and function calls.
\n
The highlighting is lexical rather than compiler-backed. It improves readability and gives immediate visual structure to a snippet, but it does not attempt full semantic analysis, type resolution, or language-server diagnostics.
\n
Compiler errors still come from the real compilation step. Vix Reply continues to present structured compiler diagnostics after execution rather than treating terminal highlighting as a replacement for the compiler.
\n
Color output follows terminal capabilities. NO_COLOR is respected, and highlighting is disabled when Reply is running in a non-interactive environment where terminal color sequences would be inappropriate.
\n
Indentation and code editing
\n
C++ mode now tracks block depth and applies automatic indentation when a new line is created inside braces.
\n
Entering a closing brace automatically dedents the current line to the appropriate level. Tab and Shift+Tab can also indent or unindent the active code line manually.
\n
The Tab key has different behavior inside native C++ mode than in the regular Reply prompt. It edits code indentation instead of opening command completion. This prevents the normal Reply completion menu from interrupting snippet editing.
\n
Backspace understands indentation levels at the beginning of a line and can remove one level cleanly rather than deleting whitespace one character at a time.
\n
The editor also preserves the source as it was entered. Indentation is no longer removed before a snippet is stored or executed, and empty lines inside a snippet remain part of the source without being converted into indentation-only lines.
\n
Continuation prompts now align with the first C++ input line, making multi-line functions and blocks easier to read in the terminal.
\n
Optional Vi keymap
\n
Vix Reply now includes an initial Vi-style editing mode.
\n
It can be enabled with:
\n
VIX_REPLY_KEYMAP=vi vix
The first version focuses on a small set of navigation and editing commands:
\n
h move left\nl move right\n0 move to the beginning\n$ move to the end\nw move to the next word\nb move to the previous word\ni enter insert mode\na insert after the cursor\nI insert at the beginning\nA insert at the end\nx delete the current character
This is not intended to provide complete Vim compatibility. It establishes the editor state model and the most useful navigation commands without making the initial implementation difficult to understand or maintain.
\n
The regular terminal keymap remains the default.
\n
Global installation of CLI packages
\n
This release fixes an installation problem affecting some header-only packages that also build a command-line executable.
\n
A package may be header-only as a library while still defining an executable target for a developer tool. Some of these packages do not provide an explicit CMake rule such as:
Previous versions of vix install -g could build the executable successfully but fail to place it in the Vix global binary directory because the CMake install step had no runtime target to install.
\n
Vix now detects the generated executable in this case and copies it into:
\n
~/.vix/global/bin
When that directory is present on PATH, the command becomes available immediately.
\n
Packages that already provide correct install(TARGETS ...) rules continue to use the standard CMake installation process. The fallback is used only when the package produces an executable but does not install it itself.
\n
Vix Note asset resolution
\n
The vix note launcher now prefers installed frontend assets over stale assets left in a build directory.
\n
This fixes cases where the executable had been updated but Note opened an older frontend from a previous local build. Installed deployments now resolve the assets associated with the installed version before considering development build-tree locations.
\n
The change keeps the application code and interface version aligned when Vix is installed or upgraded.
\n
Validation
\n
The extension system was validated across discovery, package management, document storage, frontend integration, and external execution.
\n
The Vix Note module and Vix CLI were built successfully with the new extension infrastructure. Built-in extensions were discovered through vix note --list-extensions, and the install, enable, disable, and removal workflows were exercised through the extension manager.
\n
Custom cell preservation was tested with Python cells by loading, saving, and reopening .vixnote documents. The /api/extensions endpoint was verified against the active extension registry, and execution was tested through a temporary external runtime implementing the vix-note-extension-1 protocol.
\n
Registry search behavior was verified with both extension-aware and normal queries:
A regression test now covers global installation of a header-only package that produces a CLI executable without CMake runtime installation rules.
\n
The complete Vix project was also built with the updated Reply module. Interactive verification covered syntax highlighting, automatic indentation, closing-brace dedentation, Tab, Shift+Tab, Backspace, arrow-key navigation, Home, End, Delete, and insertion in the middle of an existing line.
\n
Native C++ snippet execution and structured compiler diagnostics were tested after the editor changes. The optional Vi keymap was verified with VIX_REPLY_KEYMAP=vi, and the updated Reply code builds without unused-function warnings.
\n
Compatibility
\n
Existing Markdown, HTML, C++, and Reply cells remain available. Their implementation now passes through the extension architecture, but the normal notebook workflow does not require users to install separate packages for these built-in types.
\n
Existing .vixnote documents remain compatible. Documents can also contain external cell types without losing them when the corresponding extension is missing.
\n
Registry packages that do not declare Note extensions continue to use the normal package workflow. Packages with valid extensions.note metadata gain the additional search, discovery, and management behavior introduced in this release.
\n
The global installation fix does not replace standard CMake installation rules. Packages with an explicit runtime installation target continue to follow their existing install process.
\n
Known limitations
\n
External extension runtimes currently use one-shot processes. A new process is created for each execution, so the system does not yet provide persistent language kernels or reusable interactive sessions.
\n
External process execution is currently available on POSIX platforms. On Windows, Vix Note reports an explicit unsupported runtime error rather than attempting an incomplete execution path.
\n
Interactive permission prompts are not yet implemented. The manifest can describe permissions, but a complete user approval and permission persistence workflow will require additional work.
\n
Extensions cannot yet provide frontend JavaScript, load through a native C ABI, or request an automatic local runtime build. These areas require stricter isolation, compatibility, and lifecycle rules before they can be supported safely.
\n
Additional end-to-end CTest coverage is also planned for the complete extension lifecycle.
\n
Vix Reply highlighting remains lexical and does not replace compiler-backed semantic tooling. The optional Vi keymap provides an initial focused command set rather than full Vim behavior.
\n
Release summary
\n
Vix.cpp v2.7.7 gives Vix Note an extension boundary that fits the rest of the Vix ecosystem.
\n
Extensions are ordinary packages. They can be published through the Vix Registry, discovered from local or global installations, managed from the Note interface, and executed through a language-independent protocol. Custom cell types remain part of the document even when their runtime is unavailable.
\n
The Reply update improves a different part of the workflow: writing and testing native C++ directly in the terminal. Cursor-aware editing, highlighting, indentation, keyboard shortcuts, and the initial Vi mode make snippet entry more practical without changing the underlying compile-and-run model.
\n
Together with the global CLI installation and Note asset fixes, the release makes Vix more extensible while improving the reliability of the tools developers already use.
\n';
+const v2_7_7 = {
+ html
+};
+export {
+ v2_7_7 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.8-C8-MN9er.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.8-C8-MN9er.js
new file mode 100644
index 000000000..e638960c4
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.7.8-C8-MN9er.js
@@ -0,0 +1,8 @@
+const html = '\n
Vix.cpp v2.7.8
\n
Vix.cpp v2.7.8 introduces first-class support for moving packages between repositories, namespaces, and package names without abandoning their existing registry history.
\n
A package can now continue under a new identity while preserving its published versions, documentation, maintainers, keywords, and repository information. The previous package remains in the registry as a deprecated entry that points developers and package commands toward its replacement.
\n
This release also completes the migration workflow across vix publish, vix add, vix outdated, and vix update. Package moves are no longer only registry metadata; they are understood throughout dependency installation, lockfile generation, version checks, and project updates.
\n
Alongside the registry work, vix publish can now create its registry pull request automatically, dependency-only workspace packages can be published without public headers, and vix build once again supports Vix installations discovered through normal CMake mechanisms when no compatible managed SDK profile is available.
\n
Release focus
\n
Package identities sometimes need to change.
\n
A project may move from a personal namespace to an organization, split one repository into several packages, adopt clearer package names, or transfer ownership to a new team. Before v2.7.8, such a change usually required publishing a separate package and manually explaining that the previous identity should no longer be used.
\n
That approach loses continuity. Existing users may continue installing the old package, dependent projects may retain obsolete identifiers, and the registry presents the replacement as an unrelated project even when both packages share the same source history.
\n
Vix.cpp v2.7.8 treats these changes as migrations rather than independent publications.
\n
The registry records the relationship between the previous and replacement identities. Package commands follow that relationship when resolving dependencies, and project manifests are updated to use the replacement package rather than keeping both names in the dependency graph.
\n
The result is a package move that remains visible and traceable without requiring users to reconstruct the relationship manually.
\n
Package moves and namespace migrations
\n
vix publish can now detect when an existing registry package has moved to a different repository location, namespace, or package name.
\n
For example, a package previously published as:
\n
softadastra/kordex-runtime
can continue as:
\n
kordexjs/runtime
The replacement entry preserves the package history associated with the original project, including:
\n
\n
published versions;
\n
package metadata;
\n
documentation;
\n
maintainers;
\n
keywords;
\n
repository information.
\n
\n
The previous package is not removed from the registry. It is marked as deprecated and receives a movedTo field pointing to the replacement identity. The replacement package receives a corresponding migratedFrom field.
\n
This keeps old links and package references meaningful. A developer who encounters the previous package can still understand where the project moved, while new installations can resolve directly to the maintained identity.
\n
Migration detection during publication
\n
Package moves are detected using repository identity and shared Git history.
\n
Repository URLs alone are not sufficient because repositories themselves can move between owners or organizations. Package names are also not sufficient because a project may deliberately change its namespace or split its publication layout.
\n
By considering both repository identity and Git history, vix publish can distinguish a real project migration from an unrelated package that happens to use similar metadata.
\n
When a move is detected, the publication workflow prepares both sides of the migration:
\n
\n
the previous package is updated with its replacement;
\n
the replacement package records its previous identity;
\n
existing versions and metadata are carried into the new registry entry;
\n
the publication commit and pull request describe the move explicitly.
\n
\n
The migration remains part of the normal registry review process. It is represented as a clear change to the registry rather than an invisible redirect controlled only by the CLI.
\n
Automatic registry pull requests
\n
vix publish now creates the registry pull request after pushing the publication branch.
\n
Earlier versions could prepare and push the registry change while still requiring the developer to open the pull request separately. The command could also report a successful publication even when no pull request had been submitted, leaving the registry change incomplete.
\n
The updated workflow performs the complete submission sequence. After the branch is pushed, Vix checks for an existing pull request associated with that branch. If one already exists, it is reused. Otherwise, the command creates a new pull request and displays its URL.
\n
The pull request URL is also included in JSON output, allowing scripts and other tools to track the registry submission without parsing terminal text.
\n
For package migrations, the pull request title and description identify both package IDs. This makes the proposed move understandable during review without requiring maintainers to inspect the registry files individually.
\n
Publication now fails clearly when the pull request cannot be created. This includes cases where the GitHub CLI is unavailable, gh is not authenticated, or GitHub rejects the pull request request.
\n
A pushed branch without a corresponding registry pull request is therefore no longer reported as a completed publication.
\n
Migration support in vix add
\n
vix add now follows the movedTo relationship when a project requests a package that has been migrated.
The replacement is not added beside the previous dependency. Vix removes the old identity and writes the new package ID into the project configuration.
\n
This applies to dependencies declared in both vix.json and module manifests using vix.module. The old dependency tree is removed before the lockfile is regenerated, preventing packages reachable only through the previous identity from remaining in vix.lock.
\n
The final project state contains the replacement package and the dependency tree required by that replacement.
\n
This behavior is important for direct migrations, but it also applies when an old package appears through another dependency. The resolver can follow package moves while constructing the graph instead of treating the deprecated and replacement identities as separate packages.
\n
Moved packages in vix outdated
\n
vix outdated now reports package migrations separately from ordinary version updates.
\n
A moved package is not considered current merely because the last version published under its old identity matches the installed version. The command follows movedTo, reads the available versions from the replacement package, and compares the project against the package that is still maintained.
\n
The terminal output identifies the replacement:
\n
moved -> kordexjs/runtime
JSON output includes the migration state through the moved and moved_to fields.
\n
This distinction allows developers and automation to separate two different maintenance tasks. An ordinary outdated package needs a version update under the same identity. A moved package requires the project to adopt a different package ID, potentially alongside a newer version.
\n
Package migrations in vix update
\n
vix update can now apply the package identity change directly.
\n
When an old dependency is encountered, the command updates vix.json to use the replacement identity and regenerates vix.lock from the new package graph. Versions and hashes are then read from the replacement lockfile entry rather than from the package ID that was removed during migration.
\n
Migration reporting is also available in dry-run and JSON modes. A project can therefore inspect the planned identity changes before modifying its manifest or consume the migration result through tooling.
\n
The update workflow keeps the manifest and lockfile aligned. It does not leave the previous package name in vix.json while resolving the replacement internally, because that would cause the migration to be repeated on every update and would make the declared project state misleading.
\n
Clean dependency replacement
\n
This release fixes a migration issue where both the previous and replacement package IDs could remain in the project after a move.
\n
That state was especially problematic when the two identities exposed overlapping dependencies. The lockfile could contain duplicate branches, retain transitive packages that were no longer needed, or make it appear that the project intentionally depended on both versions of the same package.
\n
Vix now removes the previous dependency tree before resolving the replacement.
\n
After migration, vix.json and vix.lock contain only the replacement identity and the packages required by its current dependency graph.
\n
Semantic version ordering
\n
Registry version selection now uses semantic version comparison instead of lexical string ordering.
\n
Lexical ordering compares version text character by character, which can produce incorrect results for versions such as:
\n
2.9.0\n2.10.0
Under string ordering, 2.9.0 may appear greater because the comparison does not understand version components. Semantic version comparison correctly treats 2.10.0 as the newer release.
\n
This affects package resolution after migrations as well as normal registry operations. When Vix follows a moved package to its replacement, it now selects versions according to their semantic meaning rather than their textual representation.
\n
Workspace packages
\n
vix publish now supports dependency-only workspace packages.
\n
A workspace package can declare:
\n
{\n "type": "workspace"\n}
Unlike a library package, a workspace package does not need to expose public headers. Its purpose is to group related dependencies under one package identity so that a complete toolchain, framework distribution, or project environment can be installed as a unit.
\n
For example, a workspace package may depend on runtime, bindings, standard library, and command-line packages without containing a C++ library of its own.
\n
Header validation remains active for packages that publish source code or libraries. The workspace type only changes validation where public headers would not represent the role of the package.
\n
This distinction allows the registry to support aggregate packages without weakening the validation applied to normal C++ packages.
\n
SDK discovery in vix build
\n
Managed SDK profiles remain the preferred way to provide a consistent Vix development environment, but they are no longer required for every project that uses Vix.
\n
Vix can be installed in several valid ways. A developer may use a managed SDK under ~/.vix/sdk, a system package, a local source installation, a custom installation prefix, or an existing Vix installation created before SDK profiles were introduced.
\n
CMake already has established mechanisms for discovering these installations, including:
\n
\n
Vix_DIR;
\n
CMAKE_PREFIX_PATH;
\n
system installation prefixes;
\n
Conan and vcpkg toolchains;
\n
custom CMake toolchain files.
\n
\n
Previous CLI behavior could stop the configuration before CMake ran when a compatible managed profile was not installed. This prevented projects from using otherwise valid Vix installations that CMake could discover normally.
\n
Vix.cpp v2.7.8 changes that selection process.
\n
When a complete and compatible managed profile set is available, vix build continues to use it automatically. When no suitable managed profile exists, the CLI preserves the project environment and allows normal CMake package discovery to proceed.
\n
A missing managed profile is therefore no longer treated as proof that Vix is unavailable.
\n
Legacy, local, and system installations
\n
Projects using Vix outside ~/.vix/sdk no longer need to run:
\n
vix upgrade --sdk default
simply to pass the CLI configuration stage.
\n
A project can use a system installation:
\n
cmake -S . -B build
or provide an explicit prefix:
\n
vix build -- \\\n -DCMAKE_PREFIX_PATH=/opt/vix
It can also rely on an existing Vix_DIR, a package-manager toolchain, or another CMake discovery mechanism already used by the project.
\n
The CLI does not attempt to replace those environments with an incomplete managed profile. It selects the managed SDK only when the profile set is complete and compatible with the requested build.
\n
This preserves the benefits of managed profiles while keeping Vix compatible with normal CMake projects and installations created by earlier releases.
\n
Registry publication fixes
\n
The publication workflow now verifies that the registry pull request was actually created or found before reporting success.
\n
Failures from the GitHub CLI are surfaced directly. The developer receives a clear error when gh is missing, authentication is unavailable, or pull request creation fails for another reason.
\n
Existing pull requests for the same publication branch are reused rather than duplicated. This is useful when a publication command is repeated after a partial failure or when the registry branch was pushed before the pull request step completed.
\n
The resulting output now represents the real registry state: a publication is complete only when its review request exists.
\n
Lockfile lookup after migration
\n
vix update previously regenerated the lockfile using the replacement package identity but could still attempt to read version and hash information through the previous package ID.
\n
Because the old entry no longer existed in the regenerated lockfile, the command could fail after successfully performing the migration itself.
\n
The update workflow now follows the resolved identity throughout the complete operation. Once a dependency has moved, lockfile lookup, version reporting, and hash reporting all use the replacement package ID.
\n
Workspace package validation
\n
Dependency-only workspace packages were previously rejected because the publication validator expected every package to contain public headers.
\n
That rule is appropriate for libraries, but not for an aggregate package whose entire purpose is to declare a group of dependencies.
\n
Validation now considers the package type. Workspace packages can be published without public headers, while source and library packages continue to require the files expected by their publication model.
\n
Validation
\n
Package migration was validated through the Kordex namespace move:
This migration covered both individual packages and a workspace package that aggregates the complete Kordex environment.
\n
Publication tests verified that Vix could identify the shared repository history, preserve the existing registry metadata, create the replacement entries, deprecate the previous identities, and submit the registry pull requests automatically.
\n
Dependency tests covered old package IDs in vix.json, dependencies declared through vix.module, direct dependencies, and packages reached transitively. After migration, the resulting manifests and lockfiles contained only the replacement identities and their required dependency trees.
\n
The vix outdated and vix update workflows were tested in terminal, dry-run, and JSON modes. These checks verified that version information was read from the replacement package and that migration details remained available to scripts.
\n
Workspace publication was validated with packages that provide dependency aggregation without public headers.
\n
SDK discovery was tested with managed profiles, system installations, local installations, custom prefixes, and Vix installations created before managed SDK profiles were introduced. A complete Vix project was also built with the updated CLI module to verify that the fallback to normal CMake discovery did not interfere with standard managed SDK builds.
\n
Compatibility
\n
Existing packages do not need to declare migration metadata manually. Packages that have not moved continue to use the normal publication and resolution workflow.
\n
Old package identities remain present in the registry after migration, so existing references can still produce a meaningful result. Package commands redirect those references to the replacement, while the registry preserves the historical relationship between both names.
\n
Projects using current package IDs are unaffected. Projects using old identities can migrate through vix add or vix update, and vix outdated can report the move before any project files are changed.
\n
Workspace packages introduce an additional package type without changing validation for libraries and source packages.
\n
Managed SDK profiles also remain supported. The discovery change only affects the case where a complete compatible profile is unavailable. In that situation, Vix now allows CMake to use the environment already provided by the project or system.
\n
Release summary
\n
Vix.cpp v2.7.8 gives package identity changes a complete workflow across the registry and CLI.
\n
A project can move to a new repository, namespace, or package name while preserving its published history. The registry records both sides of the move, publication creates the required pull request, and package commands update projects to use the maintained identity without retaining duplicate dependencies.
\n
Workspace packages extend the registry to dependency-only package groups, while semantic version ordering makes version selection reliable for both migrated and ordinary packages.
\n
The SDK discovery changes address a separate compatibility problem. Managed profiles remain available when they are complete, but projects using system, local, custom-prefix, package-manager, or legacy Vix installations can once again rely on normal CMake discovery.
\n
Together, these changes make package moves explicit, reviewable, and practical without narrowing the ways developers can install and build with Vix.
\n';
+const v2_7_8 = {
+ html
+};
+export {
+ v2_7_8 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.8.3-fnMXoBpX.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.8.3-fnMXoBpX.js
new file mode 100644
index 000000000..dbb0c934b
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.8.3-fnMXoBpX.js
@@ -0,0 +1,8 @@
+const html = '
vix.cpp v2.8.3
\n
vix.cpp v2.8.3 is the first stable and supported release of the v2.8 line.
\n
versions v2.8.0, v2.8.1, and v2.8.2 were published while release and distribution problems were still being resolved. they remain in the project history for traceability, but they should not be used as production releases. developers using an earlier v2.8 build should move to v2.8.3.
\n
the main change in v2.8 is the introduction of vix::realtime, a transport-independent runtime for authoritative stateful applications. it provides the application model needed for rooms, commands, events, logical sessions, snapshots, replay, reconnection, presence, and persistence without tying those concepts to a particular network transport.
\n
this release is the point where that architecture is delivered as the supported v2.8 release.
\n
release focus
\n
realtime applications often begin with a websocket connection and quickly grow beyond it. once several clients share state, the difficult part is no longer opening a socket. the application needs one authoritative version of that state, a defined order for mutations, a way to recover after a process restart, and enough session information to reconnect a client without losing consistency.
\n
vix::realtime moves those responsibilities into a dedicated runtime.
\n
applications define their room state and command handling logic. vix manages the execution boundary around that logic: commands are serialized, accepted state changes become authoritative events, events can be persisted, snapshots can be created, rooms can be restored, and logical sessions can continue across network reconnections.
\n
the runtime is deliberately separate from websocket. a websocket adapter is available, but rooms, sessions, replay, persistence, and state recovery belong to the realtime model itself rather than to one transport implementation.
\n
authoritative rooms
\n
a realtime room owns one authoritative application state.
\n
instead of allowing multiple connections to mutate shared state independently, commands enter one serialized execution path. this gives the room a clear ordering model and prevents concurrent command handling from producing conflicting versions of the same state.
\n
applications remain responsible for the state they want to model. a room can represent a game world, collaborative document, chat room, shared dashboard, presence space, or another application-specific domain. vix provides the lifecycle and consistency machinery around that state without defining what the state itself must contain.
\n
rooms can be opened and closed explicitly, created from application-defined factories, joined by logical sessions, and configured with limits for command queues, memberships, snapshots, and inactive-room cleanup.
\n
commands, events, and room versions
\n
state changes begin as commands.
\n
a command carries the information required to identify the room, session, request, expected room version, payload, metadata, and creation time. the room handler decides whether that command is valid and which events should result from it.
\n
accepted events receive authoritative identifiers and room versions before they are persisted and applied to state. this ordering is important because persistence, replay, recovery, and client synchronization all need to refer to the same sequence of state transitions.
\n
events can be delivered to the entire room, only to the sending session, to every session except the sender, or to a selected set of sessions. audience selection is part of the realtime model, while the actual delivery remains the responsibility of the active transport adapter.
\n
this keeps application state deterministic without forcing every event to be broadcast in the same way.
\n
snapshots and deterministic recovery
\n
long-lived rooms cannot depend only on in-memory state.
\n
vix::realtime can create snapshots automatically after a configured number of events, explicitly when requested, or when a room is closed. a configurable number of recent snapshots can be retained so the persistence layer does not have to keep every historical state representation.
\n
recovery follows one consistent sequence. vix loads the latest available snapshot, restores its state and schema information, replays events created after that snapshot, restores the current room version and event position, then allows new commands to continue from the recovered point.
\n
if no snapshot exists, the runtime can rebuild the room from its persisted event history.
\n
the important property is that recovery uses the same events that originally changed the room. restoring the same persisted history therefore produces the same authoritative state and room version, and reopening a room does not duplicate events that were already stored.
\n
logical sessions
\n
network connections are temporary. application sessions usually are not.
\n
the realtime runtime therefore separates a logical session from the socket or transport connection currently carrying its messages. a session has a stable identifier, identity and metadata, room memberships, connection attachment state, a resume token, and acknowledgement positions for the rooms it has joined.
\n
a temporary connection loss does not immediately destroy that logical state.
\n
when the client reconnects, the runtime can validate the resume token, attach the new connection, restore memberships, and determine which room events the client has not yet acknowledged.
\n
this model avoids making tcp or websocket connection lifetime the source of truth for application identity.
\n
reconnection and replay
\n
a resumed session can continue from its last acknowledged event position.
\n
if the missing range is small enough, vix replays the events that were persisted while the client was disconnected. a session can maintain a different acknowledgement position for each room, which matters when one client participates in several independent realtime spaces.
\n
when the client is too far behind for bounded replay, the runtime can fall back to a snapshot. the client receives the latest available room snapshot, the events created after that snapshot, and the final replay position.
\n
this keeps reconnection practical even for rooms with long histories. a stale client does not need to replay every event that has ever existed before it can become current again.
\n
presence
\n
presence is modeled separately from room state.
\n
the initial runtime includes local presence tracking for sessions inside rooms. presence records can carry identity, node ownership, connection information, metadata, heartbeat timestamps, and lifecycle state.
\n
a session can be present, temporarily detached, or explicitly left. expiration and stale-record cleanup make it possible to distinguish a short connection interruption from a session that should no longer appear in the room.
\n
keeping presence separate from application state also avoids forcing every room implementation to rebuild the same connection-awareness logic.
\n
room management
\n
roommanager coordinates the runtime-level relationship between rooms, sessions, stores, presence, factories, and command routing.
\n
it can register room factories, open and locate rooms, create and find logical sessions, join and leave memberships, attach and detach transport connections, route commands, enforce configured limits, clean up inactive rooms, and participate in controlled runtime shutdown.
\n
the module also introduces room directory and ownership abstractions. an active room can be associated with the node responsible for its authoritative execution.
\n
the first release still focuses on the local runtime, but separating room identity from node ownership provides the boundary needed for future multi-process and distributed routing.
\n
persistence stores
\n
persistence is exposed through interfaces rather than being embedded directly in room implementations.
\n
the realtime runtime defines stores for room events, room snapshots, and presence records. the initial implementation includes in-memory event and snapshot stores, along with local in-memory presence storage.
\n
an application can therefore begin with a completely local runtime and later replace the persistence layer without changing its room state or command handlers.
\n
optional postgresql event and snapshot stores are also available. postgresql support is independent from the transport layer, so persistent rooms do not require websocket and websocket applications do not require postgresql.
\n
websocket adapter
\n
vix::realtime can be used without websocket support.
\n
for applications that do use vix::websocket, v2.8 adds an adapter between the transport and the realtime runtime. the adapter handles the connection-facing parts of the protocol, including session opening and resumption, room joins and leaves, command forwarding, event delivery, acknowledgements, protocol errors, and connection backpressure.
\n
the separation is intentional. websocket answers how messages move between a client and server. the realtime runtime answers how shared application state is ordered, persisted, recovered, and associated with logical sessions.
\n
keeping those responsibilities distinct allows another transport to reuse the same room and session model later.
\n
realtime protocol
\n
the module includes a versioned protocol envelope for communication between realtime clients and servers.
\n
the protocol covers session opening and resumption, room membership, commands, command acceptance and rejection, events, snapshots, acknowledgements, replay completion, presence updates, ping and pong messages, protocol errors, and server draining notifications.
\n
protocol parsing includes version checks and structured errors so malformed or incompatible messages can be rejected at the boundary before they reach application room logic.
\n
applications that do not need the provided transport protocol can still use the underlying room runtime independently.
\n
public api
\n
the stable module entry point is:
\n
#include <vix/realtime.hpp>
advanced apis remain available through module-specific headers:
\n
#include <vix/realtime/...>
the public cmake targets are:
\n
vix_realtime\nvix::realtime
the realtime module also has standalone package metadata under:
\n
vix/realtime
its first standalone module version is 0.1.0.
\n
this keeps the realtime runtime usable both as part of the complete vix sdk and as a module with its own package boundary.
\n
examples
\n
four examples are included to exercise the runtime through complete application flows rather than isolated api calls.
\n
the counter example demonstrates commands, deterministic events, automatic snapshots, state restoration, and continued room versions after recovery.
\n
the shared-room example uses multiple sessions against one authoritative state and shows room membership together with room-wide event delivery.
\n
the chat example adds persistent messages, room history, snapshots, and restoration.
\n
the reconnect example exercises acknowledgements, temporary disconnection, resume-token validation, missing-event replay, snapshot fallback, and restoration of the final authoritative state.
\n
these examples are useful because they test the boundaries between features. reconnection depends on sessions, acknowledgements, persistence, replay, and room state all agreeing on the same history.
\n
release stabilization
\n
the first three v2.8 tags should be treated as superseded release attempts.
\n
v2.8.0 introduced the new realtime architecture, but the release line still had distribution and packaging problems. v2.8.1 and v2.8.2 continued the stabilization work, including fixes to standalone module dependencies, but they were not accepted as stable releases.
\n
for that reason, the supported v2.8 line begins with v2.8.3.
\n
the older tags remain available because removing them would erase useful release history and make existing references harder to understand. their presence should not be interpreted as a recommendation to install them.
\n
if a machine or ci environment is pinned to v2.8.0, v2.8.1, or v2.8.2, update that pin to v2.8.3.
\n
validation
\n
the realtime module has dedicated strict ci coverage across gcc and clang, debug and release configurations, websocket-enabled and transport-independent builds, examples, sanitizers, compiler warnings, static analysis, memory checks, postgresql store compilation, package metadata, and cmake package contracts.
\n
the test suite covers identifiers, commands, events, protocol parsing and round trips, room state, persistence stores, snapshot policy, sessions, presence, room lifecycle, command backpressure, ownership, room management, the websocket adapter, resume tokens, reconnection replay, snapshot fallback, and complete realtime session flows.
\n
the four runtime examples were also executed as part of validation:
\n
counter\nshared_room\nchat\nreconnect
the recovery tests verify monotonic room versions and event identifiers, event persistence, automatic snapshots, restoration after snapshots, full replay when no snapshot exists, continued execution after recovery, replay from acknowledged positions, and snapshot fallback for stale clients.
\n
the release was also checked through the standalone module and packaged-runtime paths so that the supported tag represents more than a successful source-tree build.
\n
compatibility
\n
vix::realtime is a new module and does not replace the existing websocket runtime.
\n
applications that only need websocket messaging can continue using vix::websocket directly. applications that need authoritative state, session recovery, replay, or persistent rooms can place the realtime runtime above the transport layer and use the websocket adapter when appropriate.
\n
postgresql support remains optional. in-memory stores are available for local applications, tests, and simpler deployments.
\n
the public realtime umbrella header and cmake targets provide the stable entry points. lower-level headers remain available for applications that need more direct control over stores, protocols, sessions, or room management.
\n
upgrade notes
\n
do not use v2.8.0, v2.8.1, or v2.8.2 for a new installation.
\n
existing users of one of those versions should move to v2.8.3 and verify the installed version with:
\n
vix --version
projects using the realtime module should also rebuild against the v2.8.3 sdk or package set rather than carrying binaries or generated build state from one of the superseded releases.
\n
release summary
\n
vix.cpp v2.8.3 establishes the supported foundation for stateful realtime applications in vix.
\n
the new vix::realtime module gives shared application state an explicit execution and recovery model: rooms serialize commands, accepted changes become deterministic events, snapshots bound recovery cost, logical sessions survive temporary connection loss, acknowledgements define replay positions, and persistence remains replaceable behind store interfaces.
\n
websocket is available as an adapter rather than being the architecture itself, and postgresql can be added when persistent room history is required.
\n
most importantly for the v2.8 release line, v2.8.3 is the version developers should actually install. v2.8.0, v2.8.1, and v2.8.2 remain in history as superseded release attempts; v2.8.3 is the first stable and supported v2.8 release.
\n';
+const v2_8_3 = {
+ html
+};
+export {
+ v2_8_3 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.8.4-D4HeF3Zi.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.8.4-D4HeF3Zi.js
new file mode 100644
index 000000000..2056f11d5
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.8.4-D4HeF3Zi.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.8.4
\n
Vix.cpp v2.8.4 focuses on the part of development that is repeated most often: edit, build, run, change a file, and build again.
\n
The release reduces unnecessary compiler work in Vix public headers, improves the way standalone programs and full projects reuse previous build state, and brings vix build, vix run, and vix dev closer to one consistent execution model. It also tightens cache invalidation, improves diagnostics, and avoids consuming every available hardware thread during normal builds.
\n
The result is not a new application model or a new module. It is a refinement of the development loop itself, with most of the work aimed at making common C++ workflows faster without hiding the information developers need when something goes wrong.
\n
Release focus
\n
C++ build performance is affected by more than the compiler command that eventually runs.
\n
A public header can force large implementation dependencies into every translation unit. A cache can save time when its inputs are correct, but create confusing behavior when dependency tracking is incomplete. A development watcher can rebuild quickly while still feeling slow if it performs redundant validation, restarts twice for one change, or floods the terminal with internal state.
\n
v2.8.4 addresses these problems together.
\n
The public API has been made lighter where implementation details did not need to be visible. Standalone C++ execution keeps a direct compilation path when possible, while code that depends on compiled Vix libraries uses the CMake-backed path needed for correct linkage. Build caches now track source and header content more carefully, and the watch paths used by vix dev and vix build --watch share more of the same underlying behavior.
\n
The goal is simple: unchanged work should not be repeated, changed work should invalidate the right artifacts, and the terminal should make it clear what Vix is doing.
\n
A unified vix build experience
\n
vix build now uses one compact live build presentation across native builds, graph-executor builds, and CMake/Ninja builds.
\n
The normal command remains:
\n
vix build
Verbose mode uses the same presentation instead of switching to a different build experience:
\n
vix build -v
-v adds useful toolchain and build information while preserving the higher-level Vix output. Developers who need Vix's own structured diagnostics can use:
\n
vix build --debug
Raw CMake, Ninja, and compiler output remains available through:
\n
vix build --cmake-verbose
Build logs can also be inspected directly:
\n
vix build --log
This separation keeps the default build readable without removing access to the lower-level tools. Normal development can stay concise, while build-system investigation still has an explicit path to the complete output.
\n
Cross-compilation controls
\n
The build command now exposes clearer controls for selecting native and cross-compilation environments.
\n
The host platform can be selected explicitly with:
\n
vix build --target native
Available native and cross toolchains can be inspected with:
\n
vix build --targets
Target toolchains can also receive an explicit sysroot through --sysroot.
\n
These options make target selection visible at the Vix CLI level rather than relying entirely on implicit toolchain state. They do not replace CMake toolchains, but give the build command a clearer way to participate in cross-platform configuration.
\n
Lighter public headers
\n
A significant part of the work in v2.8.4 is below the CLI.
\n
Vix public headers previously exposed more implementation detail than many applications needed. Including a high-level type could indirectly pull router internals, HTTP server implementation, request handling, runtime execution details, Asio types, JSON-heavy configuration code, or logging implementation into user translation units.
\n
That increases parsing and template work even when an application only uses a small part of the public API.
\n
The App interface has now been decoupled from several of those implementation details. Router, HTTP server, request handler, runtime executor, and Asio internals are no longer exposed unnecessarily through the main application surface.
\n
The core umbrella path has also been reduced. Including <vix.hpp> no longer means importing advanced HTTP and router implementation headers that are unrelated to the code being compiled.
\n
JSON-heavy Config implementation has been moved out of headers where possible. Response implementation follows the same direction, logger internals no longer expose spdlog throughout user translation units, and RuntimeExecutor lifecycle implementation is kept outside application translation units where the public API does not require it.
\n
These changes preserve common public workflows such as GET routes, POST JSON handling, middleware, configuration, logging, and runtime executors. The change is primarily about reducing what the compiler must see to use those APIs.
\n
Faster standalone execution
\n
vix run now distinguishes more carefully between standalone C++ programs that can use direct compilation and programs that require compiled Vix runtime functionality.
\n
A simple file can continue through the lightweight path:
\n
vix run test.cpp
When the source requires compiled Vix libraries, Vix uses the CMake-backed path so that the program receives the correct targets, libraries, and transitive linkage.
\n
This avoids two opposite problems: forcing every small script through a full project build, or trying to compile a program directly when its dependencies require the compiled Vix runtime.
\n
Warm executions reuse validated build state and compiled artifacts. When neither the source nor one of its relevant dependencies has changed, an unchanged script can run without invoking the compiler or linker again.
\n
Local and transitive dependencies remain part of validation, so the faster path does not treat the top-level source file as the only input that matters.
\n
Explicit vix run controls
\n
Runtime options that were previously driven mainly through internal configuration or environment variables are now exposed as documented CLI controls.
These options make runtime behavior easier to reproduce from a command line or CI script.
\n
The compiler fingerprint mode is particularly useful when choosing how aggressively cached compilation state should be reused. The default development path can remain fast, while stricter validation is available when the environment or toolchain needs to be checked more carefully.
\n
Dependency-aware caching
\n
A fast cache is only useful when its invalidation rules are trustworthy.
\n
Script caching now tracks source files together with local and transitive headers by content. Editing a header that affects a standalone program invalidates the relevant build even when the top-level .cpp file is unchanged.
\n
The reverse case is also important: touching a file without changing its contents should not force compilation simply because its timestamp changed.
\n
v2.8.4 uses content-aware dependency information to distinguish those cases more reliably.
\n
Failed compilations are not stored as successful cache states, and compiled dependency graphs are rebuilt only when their inputs require it. Previously compiled source states can also be restored efficiently through the compiler cache when development moves back to code that has already been built.
\n
This makes the cache useful during real editing patterns rather than only during repeated execution of an untouched file.
\n
Faster vix dev for standalone files
\n
The standalone development loop has been simplified around the information a developer normally needs: what is being watched, whether the rebuild succeeded, how long it took, and what the program printed.
\n
A normal session can now look like:
\n
Watching test.cpp\nHello, world\nRebuilt test.cpp in 488ms\nHello, world
Internal reload messages, absolute paths, process identifiers, and build-system detail are no longer printed by default when they do not help explain the rebuild.
\n
Fast recompilations also avoid showing progress UI that lasts longer than the work itself. When a rebuild completes, its duration is reported directly and application output follows without unnecessary blank lines.
\n
The watcher tracks both the source and its transitive headers. One relevant change results in one rebuild and restart rather than several reactions to the same edit.
\n
A failed build does not leave the development session in a broken state. Once the source is corrected, the watcher can rebuild and start the program again normally.
\n
Project development builds
\n
Full Vix projects keep the project-level development experience, but rebuild timing now reflects the real build duration.
\n
For example:
\n
Dev shop (dev)\n\n changed: src/main.cpp\n\n build [============================] done\n\n ✔ Rebuilt in 7.3s · Started pid=49809
The project path still has more work to perform than a standalone file, so it retains the build progress and process information that are useful for a running application.
\n
The important change is that vix dev and vix build --watch now follow the same underlying build behavior instead of evolving as separate rebuild systems. Cache decisions, source changes, dependency handling, and build execution are therefore less likely to disagree depending on which watch command is used.
\n
Safer build parallelism
\n
Using every hardware thread is not always the fastest development experience.
\n
A large parallel C++ build can saturate the machine, increase memory pressure, and make the editor, browser, terminal, or other development tools noticeably less responsive.
\n
Automatic parallelism now keeps part of the machine available instead of assuming that every detected hardware thread should be occupied by compilation.
\n
The recommendation adapts to the available CPU resources. Developers who want a specific level of parallelism can still override it explicitly with --jobs.
\n
This changes the default, not the control available to experienced users.
\n
Correct compiled-library linkage
\n
The distinction between direct standalone compilation and compiled Vix functionality exposed several cases where a source file could compile but fail at link time because required implementations lived in Vix libraries rather than in headers.
\n
v2.8.4 fixes that boundary.
\n
Programs that depend on compiled Vix components now use a build path that has access to the correct generated CMake targets and their transitive dependencies. The direct path remains for programs that can genuinely be compiled as standalone translation units.
\n
Linker errors have also been made clearer when an implementation or required library is still missing, so failures point toward the linkage problem rather than appearing as an unrelated cache or script error.
\n
Local build-tree consumption
\n
Vix can now be consumed more reliably directly from the current build tree.
\n
Local build-tree CMake package exports have been corrected so a project can resolve the Vix targets produced by the current source build without silently falling back to an installed runtime.
\n
This matters when developing Vix itself, testing changes against another local project, or validating an installation before publishing it.
\n
Reducing transitive public includes also exposed headers that had been relying on unrelated includes to compile. Those direct dependencies have been corrected so public headers remain self-contained under the lighter include model.
\n
Build cache and configuration fixes
\n
Several fixes in this release address cases where valid reusable build state existed but was ignored, or where stale state was accepted when it should have been invalidated.
\n
--fast builds now reuse compatible configuration state correctly.
\n
Graph-executor builds are no longer bypassed by unrelated cache paths, and generated CMake targets used for script builds are handled consistently.
\n
Standalone script execution avoids redundant cache validation, while transitive compiled dependencies are rebuilt when one of their relevant inputs changes.
\n
Build-log lookup has also been corrected when a build directory is passed explicitly, so vix build --log resolves the log associated with the selected build instead of relying on unrelated default state.
\n
Server startup reporting
\n
Runtime startup now distinguishes more carefully between starting a process and successfully starting a server.
\n
READY is emitted only after startup has actually succeeded.
\n
Port configuration is propagated correctly, and bind failures are returned through the normal error path rather than allowing the process to appear ready before the listening socket exists.
\n
This is especially important for development tooling and automation that uses startup output as a signal that the application can receive requests.
\n
Diagnostics
\n
v2.8.4 separates normal build output from diagnostic depth more clearly.
\n
The default build remains compact. -v adds useful Vix-level information, --debug exposes structured internal diagnostics, and --cmake-verbose provides the raw output from the underlying CMake, Ninja, and compiler tools.
\n
This means a developer can increase detail according to the problem being investigated instead of choosing between an overly quiet command and an uncontrolled stream of build-system output.
\n
Link failures, cache decisions, build-path selection, and startup failures now have clearer places in that diagnostic model.
\n
Validation
\n
The release was validated across standalone C++ files, complete Vix projects, direct script compilation, CMake-backed script builds, graph-executor builds, watched development sessions, local headers, transitive headers, and compiled Vix dependencies.
\n
Cache testing covered unchanged warm runs, source changes, direct header changes, transitive header changes, timestamp-only file touches, failed compilations, recovery after a failed build, and restoration of previously compiled source states.
\n
Development watching was tested for one-change/one-rebuild behavior, rebuild timing, process restart, application output, and recovery after compilation errors.
\n
The public-header work was checked against common application APIs including routing, JSON requests and responses, middleware, configuration, logging, and runtime execution.
\n
Build validation also covered managed and local build paths, generated CMake targets, graph execution, reusable configuration state, build-log resolution, startup readiness, port binding failures, and direct consumption of Vix from its current build tree.
\n
Compatibility
\n
The public API used by normal Vix applications remains compatible. The header changes move implementation details out of user translation units rather than replacing the high-level interfaces developers already use.
\n
Standalone programs still use direct compilation when their dependency model allows it. Programs that require compiled Vix functionality may now take the CMake-backed path where necessary for correct linkage.
\n
Existing explicit --jobs values continue to take precedence over automatic parallelism.
\n
--cmake-verbose remains available for developers who need the complete underlying build output, while the normal and -v modes use the unified Vix presentation.
\n
The cache changes may cause an initial rebuild where older cache state cannot be validated under the new dependency rules. Once rebuilt, subsequent warm runs can reuse the new state normally.
\n
Release summary
\n
Vix.cpp v2.8.4 improves the daily C++ development loop rather than adding another layer to it.
\n
Public headers require less compiler work, standalone programs can reuse validated artifacts more effectively, and programs that depend on compiled Vix libraries now take the build path required for correct linkage. vix dev reacts to source and header changes with less terminal noise, while vix build --watch follows the same underlying behavior.
\n
Caching is more careful about real content changes, build parallelism leaves room for the rest of the development environment, and diagnostics are divided more clearly between normal output, Vix debugging information, and raw CMake or compiler output.
\n
The common workflow remains the same:
\n
edit -> build -> run -> change -> rebuild
v2.8.4 makes each pass through that loop more predictable and avoids repeating work that has already been proven valid.
\n';
+const v2_8_4 = {
+ html
+};
+export {
+ v2_8_4 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.8.5-CIYTmGNE.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.8.5-CIYTmGNE.js
new file mode 100644
index 000000000..aa1b845b1
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.8.5-CIYTmGNE.js
@@ -0,0 +1,8 @@
+const html = '
Vix.cpp v2.8.5
\n
Vix.cpp v2.8.5 stabilizes the Realtime module and strengthens the dependency model used by modular Vix applications.
\n
The release focuses on two areas that become increasingly important as projects grow. Realtime applications need reliable persistence, recovery, session handling, packaging, and concurrency behavior. Modular applications need equally reliable dependency ownership, graph validation, lockfile behavior, and project mutations.
\n
v2.8.5 brings those concerns under stricter contracts.
\n
Git dependencies can now belong to individual application modules, module relationships are validated through a canonical graph before CMake generation, dependency conflicts are detected across the application and its active modules, and project metadata changes are applied transactionally so partial failures do not leave vix.app, vix.module, or vix.lock in inconsistent states.
\n
At the same time, Vix Realtime has completed another stabilization pass across persistence, recovery, presence, session resume, SDK packaging, PostgreSQL support, protocol integration, and concurrency behavior.
\n
Release focus
\n
Application modules give larger C++ projects a clearer internal structure. Once modules can own their own dependencies, however, package management can no longer treat the project as one flat list of libraries.
\n
The build system needs to know which module owns a dependency, whether two modules request compatible versions of the same package, whether a dependency belongs to the root application or a child module, and whether the resulting module graph can be built deterministically.
\n
Those checks should happen before generated CMake files are produced.
\n
The same problem exists when changing project metadata. Installing or removing a dependency can affect several files at once. If one write succeeds and a later operation fails, a project can be left with a manifest that no longer matches its lockfile.
\n
v2.8.5 addresses both problems by giving module structure and project mutations explicit models rather than relying on command-specific behavior.
\n
Vix Realtime stabilization
\n
vix::realtime continues to provide the authoritative state model introduced in the v2.8 line.
\n
The module includes stateful rooms, serialized command execution, persisted events, snapshots, event replay, logical sessions, reconnection, presence, persistence abstractions, and optional WebSocket and PostgreSQL integrations.
\n
v2.8.5 focuses on stabilizing how these pieces behave together.
\n
Authoritative room state can be reconstructed from persisted history, snapshots are handled transactionally, replay continues from deterministic event positions, and session resume restores the state needed for a client to continue after disconnection.
\n
Presence lifecycle behavior has also been tightened around connection attachment, detachment, expiration, and session recovery.
\n
The release validates both in-memory and PostgreSQL persistence paths so application behavior does not depend on which store is selected.
\n
Realtime persistence and recovery
\n
Realtime persistence is designed around events and snapshots rather than direct mutation of stored room state.
\n
Accepted commands produce authoritative events. Those events are persisted in order, applied to the room, and used later when the room must be reconstructed.
\n
Snapshots reduce the cost of restoring long histories. Recovery can load the latest valid snapshot and replay only the events that follow it.
\n
v2.8.5 strengthens the contracts around that process.
\n
Snapshot creation, persistence, replay, room version restoration, and session resume are validated together rather than as isolated features. Recovery paths are expected to preserve the same authoritative state, room version, and event ordering that existed before the room was stopped.
\n
The PostgreSQL implementation follows the same model as the in-memory stores so applications can move between local and persistent environments without changing room logic.
\n
Session resume and presence
\n
Realtime sessions remain separate from individual network connections.
\n
A temporary transport failure can detach a connection while the logical session, room memberships, acknowledgement positions, and resume information remain available.
\n
When a client reconnects, session resume can restore its relationship with the rooms it previously joined and replay events that were not acknowledged before the disconnection.
\n
Presence follows the same lifecycle.
\n
A session can become detached without immediately being treated as gone. Expiration and cleanup rules determine when stale presence should be removed, while successful session recovery can restore active presence without creating a second logical participant.
\n
v2.8.5 validates these transitions more strictly across connection loss, resume, room membership, replay, and presence recovery.
\n
Realtime SDK packaging
\n
Realtime is now treated as a first-class installable Vix module.
\n
Its public SDK surface is packaged with isolated headers and the module can be consumed without depending on private build-tree layout.
\n
This matters for two different workflows.
\n
Applications using the complete Vix SDK need the realtime headers and CMake targets to behave like other Vix modules. Standalone package consumers need the module to expose only what belongs to its public contract.
\n
The packaging work in v2.8.5 validates both cases and checks that Realtime remains usable when installed independently from the development source tree.
\n
Metrics and health APIs
\n
The Realtime module now exposes metrics and health interfaces for observing runtime state.
\n
These APIs provide a stable place for applications and infrastructure tooling to inspect the runtime without reaching into internal room, store, or connection implementation.
\n
They are intended to support operational checks around room activity, persistence, recovery, and runtime health while keeping those concerns separate from application command handlers.
\n
Module-scoped Git dependencies
\n
Git dependencies can now be assigned directly to an application module.
The dependency is written to the target module's vix.module rather than to the root application manifest.
\n
The project still uses one root vix.lock and the shared Vix dependency cache.
\n
This separation is deliberate. Dependency ownership belongs to the module that uses the package, while dependency resolution and reproducibility remain project-wide concerns.
\n
A module therefore does not receive its own independent lockfile or duplicate Git checkout simply because it owns a dependency.
\n
Dependency ownership
\n
v2.8.5 introduces explicit dependency ownership across the application and its modules.
\n
A dependency can belong to the root application or to one of its active modules. That information is carried into graph analysis and generated integration.
\n
This prevents one module from accidentally inheriting a sibling module's private dependency simply because both are part of the same project.
\n
For example, if auth declares a Git dependency, another module does not automatically receive that target unless the application architecture makes the relationship explicit.
\n
The build graph can therefore reflect the project structure rather than flattening every dependency into one global CMake target list.
\n
Shared dependencies across modules
\n
Isolation does not require duplication.
\n
Two modules can depend on the same package when their requirements are compatible. Vix can resolve the package once, record it once in the root lockfile, and reuse the same cached checkout and resolved target for both module owners.
\n
This gives the project one deterministic dependency graph while preserving ownership information.
\n
The important distinction is between package identity and package ownership.
\n
The resolved dependency can be shared, but Vix still knows which modules requested it and can validate whether their requirements agree.
\n
Canonical module manifests
\n
vix.module is now represented through a canonical ModuleManifest model.
\n
Instead of individual commands parsing module metadata differently, the CLI has one normalized representation for module identity, paths, dependencies, and configuration.
\n
This reduces a class of inconsistencies where one command could accept a module declaration that another interpreted differently.
\n
The canonical model also provides the input needed for architecture validation before generated build files are written.
\n
Canonical module graph
\n
The application module structure is now represented through a canonical ModuleGraph.
\n
The graph tracks module identity, normalized paths, dependencies between modules, cycles, and deterministic dependency ordering.
\n
This means module validation is no longer limited to checking whether a directory or manifest exists.
\n
Vix can reason about the architecture as a complete graph before build generation begins.
\n
The graph detects:
\n
\n
normalized module-name collisions;
\n
module path collisions;
\n
references to invalid modules;
\n
dependencies on disabled modules;
\n
self-dependencies;
\n
dependency cycles.
\n
\n
The resulting module order is deterministic, so equivalent project metadata produces the same dependency ordering across runs.
\n
Cross-module dependency constraints
\n
Module dependency requirements are now analyzed together.
\n
If the root application and one or more modules request the same dependency with incompatible constraints, Vix reports the conflict before generated CMake integration is created.
\n
The same applies when two modules disagree about a Git dependency, target, revision, or other requirement that cannot be satisfied by one shared resolution.
\n
Earlier behavior could allow one declaration to overwrite another depending on processing order.
\n
v2.8.5 replaces that last-write-wins behavior with explicit conflict detection.
\n
This makes dependency resolution a property of the complete application graph rather than an accidental result of command ordering.
\n
Git dependency identity
\n
Git dependency identity has been normalized more carefully.
\n
Repository-root subdirectories that are omitted and subdirectories written as . now represent the same source location.
\n
This matters because two otherwise identical dependency declarations should not produce separate lock entries or cache identities only because one command serialized the repository root differently.
\n
The normalized identity is used when reconciling manifests, lockfiles, ownership, and cached Git checkouts.
\n
CMake dependency options
\n
CMake options associated with Git dependencies are now preserved through the lockfile and generated integration.
\n
A dependency that requires a particular configuration can therefore be resolved once and regenerated later without losing the options that were part of its original installation contract.
\n
This is particularly important for dependencies whose exported targets or generated headers depend on CMake configuration.
\n
The lockfile records enough information for Vix to reconstruct the same dependency integration rather than only remembering the repository and revision.
\n
Atomic project mutations
\n
Dependency and module changes now use project-scoped transactional mutations.
\n
Commands such as vix add, vix remove, vix update, vix install, and module mutation commands can update several project files as one logical operation.
\n
Before changing those files, Vix acquires a project mutation lock.
\n
The lock prevents two commands from modifying project metadata concurrently and silently overwriting each other's changes.
\n
Writes are staged before they replace the active project files. If a later step fails, the previous metadata can be restored instead of leaving only part of the mutation applied.
\n
Transaction rollback
\n
Failed project mutations restore the previous metadata byte-for-byte.
\n
This matters because a rollback should not merely create a logically similar manifest. It should restore the project state that existed before the command began.
\n
A failed Git resolution, invalid module target, incompatible dependency constraint, lockfile error, or other mutation failure therefore does not leave behind a partially changed vix.app, vix.module, or vix.lock.
\n
Direct Git installations use the same transactional behavior.
\n
The command can perform remote work, validate the result, and only commit the project metadata changes once the operation is known to be valid.
\n
Interrupted transaction recovery
\n
Project transactions are recorded under:
\n
.vix/transactions
If a mutation is interrupted after staging project changes, Vix can use the transaction state to recover the project rather than assuming that the partially written metadata is authoritative.
\n
This protects against a different class of failure than ordinary command errors.
\n
Rollback handles known failures inside a running command. Transaction recovery handles operations that did not get a chance to complete their own cleanup.
\n
Both paths use the same project mutation model.
\n
Safer module installation
\n
A module-scoped Git install validates the target module before performing remote work.
\n
For example, Vix checks that the module exists, is active, and can participate in the current graph before cloning or resolving the requested repository.
\n
This avoids downloading and preparing a dependency only to discover afterward that the module declaration itself is invalid.
\n
The same principle applies to dependency conflicts.
\n
Architecture and ownership checks are performed as early as possible so expensive remote operations are not used to discover problems that can already be determined from local project metadata.
\n
Smarter vix install
\n
vix install now reconciles vix.app and vix.lock instead of resolving the entire dependency set unconditionally.
\n
Only new or changed dependencies need remote resolution.
\n
Unchanged dependencies can reuse their existing resolved state, cached checkout, and generated integration.
\n
This improves both speed and predictability.
\n
An install command should not contact remote Git repositories or recreate links simply because another unrelated dependency was added to the project.
\n
When the lockfile already proves that a dependency matches its manifest declaration, Vix can preserve that result.
\n
Git cache reuse
\n
Resolved Git checkouts are reused directly from the Vix dependency cache.
\n
Multiple compatible module owners can reference the same cached dependency, and repeated installs can avoid downloading repositories that have already been resolved.
\n
This reuse remains tied to the normalized dependency identity and lockfile state.
\n
The cache is therefore an implementation optimization around deterministic dependency resolution rather than an alternative source of truth.
\n
Installation without a build-complete application
\n
Dependency operations performed by vix install no longer require a fully buildable vix.app.
\n
A project can install and reconcile dependencies while its application sources or other build-specific fields are still incomplete.
\n
This is useful during project setup, dependency recovery, and repository initialization where dependency metadata may need to be established before the application itself is ready to compile.
\n
Manifest syntax and dependency validity are still checked. The change is that dependency management is no longer unnecessarily coupled to build completeness.
\n
Git progress reporting
\n
Git installation progress now reflects actual remote activity.
\n
Vix reports remote work as it begins and surfaces real Git receiving progress instead of inventing a global percentage that cannot accurately represent the complete operation.
\n
This gives developers useful feedback during large clones or slow network operations without pretending that unrelated installation phases can be measured as one precise percentage.
\n
Install compatibility contracts
\n
v2.8.5 adds deterministic compatibility coverage for Git-hosted CMake dependencies.
\n
The contracts cover common layouts and behaviors that dependency installation must preserve, including:
\n
\n
header-only packages;
\n
static libraries;
\n
shared libraries;
\n
alias targets;
\n
generated headers;
\n
nested source subdirectories;
\n
CMake options;
\n
compile features;
\n
transitive dependencies.
\n
\n
These tests are important because a Git dependency cannot be treated as only a repository checkout.
\n
The package's exported build contract must remain correct after Vix resolves it, records it in the lockfile, and integrates it into the application or module that owns it.
\n
Module installation contracts
\n
The release also adds stricter contracts around module-scoped Git dependencies.
\n
Coverage includes ownership, graph validation, dependency constraints, rollback, transaction behavior, and installation into valid and invalid module targets.
\n
These tests verify the complete workflow rather than only checking whether a dependency can be cloned.
\n
A successful installation must leave the correct module manifest, root lockfile, ownership information, generated integration, and cached dependency state.
\n
A failed installation must leave the previous project state intact.
\n
Internal dependency isolation
\n
Vix no longer leaks its internal SPDLOG_FMT_EXTERNAL configuration into user dependencies.
\n
Internal build choices should not silently alter the configuration of unrelated third-party packages compiled as part of an application.
\n
v2.8.5 tightens that boundary so Vix's own logging configuration remains scoped to the targets that require it.
\n
Compiler warning flags have also been corrected so GCC-specific and Clang-specific options are applied only to the compiler that understands them.
\n
This reduces toolchain noise and avoids dependency builds being affected by unrelated Vix implementation settings.
\n
Validation
\n
The release was validated across Realtime, Git dependency installation, module ownership, graph construction, dependency constraints, transactional mutations, and generated CMake integration.
Dependency tests covered header-only, static, shared, and alias targets, generated headers, nested subdirectories, CMake options, compile features, and transitive dependencies.
\n
Module-scoped installation was tested with valid ownership, shared compatible dependencies, conflicting requirements, invalid modules, disabled modules, path and name collisions, self-dependencies, dependency cycles, and deterministic graph ordering.
\n
Transaction tests covered successful multi-file mutations, failures during dependency installation, rollback, concurrent mutation protection, and recovery from interrupted transaction state under .vix/transactions.
\n
Install reconciliation was also verified so unchanged dependencies can reuse lockfile and cache state without unnecessary remote Git resolution or identical generated CMake rewrites.
\n
Compatibility
\n
Existing application-level dependencies continue to work.
\n
Module-scoped ownership adds a more precise model for projects that use vix.module, but it does not require every existing dependency to move into a module.
\n
Projects continue to use one root vix.lock even when several modules own dependencies.
\n
Compatible shared dependencies can therefore remain resolved once for the complete application.
\n
The stricter graph and constraint checks may reject project states that older versions allowed through last-write-wins behavior. Those failures indicate an ambiguous or incompatible dependency model that should be resolved explicitly rather than deferred to CMake or the linker.
\n
Transaction infrastructure changes how project files are mutated, not the public manifest formats developers work with.
\n
Realtime remains compatible with the architecture introduced earlier in the v2.8 line while tightening recovery, persistence, packaging, and integration contracts.
\n
Release summary
\n
Vix.cpp v2.8.5 makes two parts of the platform substantially more dependable.
\n
Realtime now has stronger guarantees around persistence, recovery, session resume, presence, PostgreSQL integration, SDK packaging, health, metrics, and concurrency.
\n
Modular applications now have an explicit dependency architecture.
\n
Git dependencies can belong to individual modules, compatible dependencies can still be shared through one root lockfile and cache, module relationships are validated as a deterministic graph, and incompatible requirements are reported before build generation.
\n
Project mutations are also transactional. Commands that change manifests and lockfiles either complete as one operation or restore the previous state, including recovery support for interrupted transactions.
\n
The result is a more reliable foundation for Vix projects that are growing beyond a single application target, particularly projects that combine multiple modules, third-party Git dependencies, and stateful realtime systems.
\n';
+const v2_8_5 = {
+ html
+};
+export {
+ v2_8_5 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.9.0-D5WiKWjO.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.9.0-D5WiKWjO.js
new file mode 100644
index 000000000..0895dfc85
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/v2.9.0-D5WiKWjO.js
@@ -0,0 +1,8 @@
+const html = '
Vix v2.9.0
\n
Vix.cpp v2.9.0 is a release about ownership.
\n
As Vix has grown, several parts of the system had started doing work that belonged somewhere else. The build layer reconstructed information already owned by CMake and Ninja. Dependency management needed a clearer separation between what a project requests and what was actually resolved. SDK consumers could inherit machine-level requirements for dependencies that existed only because a Vix module used them internally. An asynchronous HTTP API still had places where the underlying work was not consistently asynchronous. Mobile support risked becoming useful only if Vix tried to replace the native toolchains that already understand Android and iOS best.
\n
v2.9.0 addresses these problems by making the boundaries clearer.
\n
Vix should own project intent, dependency intent, dependency resolution, toolchain configuration, diagnostics, and the developer experience. Build backends should own the concrete compilation graph and incremental execution. Internal dependencies should remain internal when Vix can reasonably package them. Platform capabilities should remain platform capabilities. An asynchronous API should stay asynchronous across the entire operation.
\n
The result is a release that removes unnecessary work from the normal development loop, makes dependency resolution more reproducible, strengthens the networking stack, makes SDKs more self-contained, and adds practical Android and iOS project support without hiding the native platforms underneath.
\n
Build: let each layer own the work it understands
\n
A build tool should not duplicate the work of its backend.
\n
Earlier Vix build paths had accumulated logic for scanning sources and headers, constructing build graphs, hashing state, and preparing information before invoking CMake and Ninja. Some of that machinery is useful for features that genuinely need a Vix-level view of the project, but it does not belong in every ordinary build.
\n
CMake and Ninja already know the concrete compilation graph. Ninja already tracks whether a source file changed, which object depends on which header, and whether a target needs to be rebuilt. Reconstructing a second version of that information in the normal Vix path added work without adding corresponding value.
\n
v2.9.0 changes that boundary.
\n
The normal build flow now lets Vix focus on the things only Vix is well placed to understand:
\n
\n
project intent
\n
selected modules and dependencies
\n
toolchain and configuration selection
\n
configuration identity
\n
backend selection
\n
command-line behavior
\n
diagnostics and presentation
\n
\n
CMake and Ninja then own the mechanics of compilation, dependency tracking, and incremental execution.
\n
This removes the need for ordinary vix build to prepare a second source and header graph before invoking the backend. Build-graph work still exists where a feature actually needs it, but normal builds, incremental builds, and no-op builds no longer pay that cost by default.
\n
The configuration model was also tightened. Presentation and execution options such as --verbose and --cmake-verbose no longer participate in build identity. Asking Vix to show more output should not create a different configuration of the program.
\n
That distinction matters because a build configuration should describe what is being built, not how much output the user wants to see while it is being built.
\n
The CLI also received clearer progress rendering and compiler diagnostics. Source frames, warnings, error presentation, and terminal hierarchy are easier to read, while users who need the backend directly can still request raw CMake, Ninja, and compiler output.
\n
The principle behind these changes is simple:
\n
\n
Vix should add value to the build, not add work to the build.
\n
\n
Dependencies: Vix can manage dependencies for CMake projects
\n
A project should not have to replace its build system just to get a better dependency workflow.
\n
v2.9.0 significantly expands vix install around that idea.
\n
Vix dependencies can now be added directly from Git repositories and used by ordinary CMake projects. The project can keep its existing CMakeLists.txt and native CMake targets while Vix manages dependency intent, resolution, locking, integrity, and local materialization.
Vix then resolves that request to an exact revision and records the reproducible result in vix.lock, including the resolved commit and package integrity metadata.
\n
This creates an important separation:
\n
\n
vix.app describes what the project requests
\n
vix.lock records the exact dependency graph that was resolved
\n
\n
A project can therefore express a human-readable dependency such as a Git tag while still reproducing the exact commit selected at resolution time.
\n
Dependencies are materialized through Vix's local package store and exposed back to the project through generated CMake integration. Vix can also understand exported CMake targets, subdirectories, header-only packages, CMake options, and transitive dependency relationships.
\n
The important part is that CMake remains CMake.
\n
A project can continue to define its library normally:
The lockfile records exact commits and integrity metadata for those dependencies, making the installed graph reproducible rather than merely remembering a floating repository reference.
\n
The goal is not to make CMake projects stop being CMake projects.
\n
The goal is to give them a simpler dependency contract:
\n
\n
Describe what the project needs, lock what was resolved, and let Vix materialize it.
\n
\n
Requests: asynchronous from beginning to end
\n
An asynchronous HTTP API is only truly asynchronous if the entire request path remains asynchronous.
\n
vix::requests has been strengthened around that idea.
\n
The asynchronous path now stays asynchronous through DNS resolution, connection establishment, TLS negotiation, request writes, and response reads. This is important not only for performance, but also for predictability. An API that appears asynchronous at its surface should not unexpectedly block because one internal stage still performs synchronous work.
\n
Connection and request lifetimes were also hardened. Networking code often fails not because the protocol itself is wrong, but because an endpoint, socket, buffer, request, or callback outlives the object that was supposed to own it, or disappears before an asynchronous operation completes. v2.9.0 strengthens those ownership boundaries so asynchronous operations keep the state they need for as long as they need it.
\n
Compatible HTTP and HTTPS connections can now be reused through an internal origin-scoped pool. A request to the same compatible origin does not need to establish a completely new connection every time when reuse is safe.
\n
Responses also gained a generic incremental body sink. Instead of always materializing the complete decoded response body in memory first, consumers can receive decoded bytes as they arrive.
\n
That changes what can be built efficiently on top of vix::requests.
\n
For example, a large download can now be written directly to disk without first allocating enough memory to hold the entire response. The CLI updater uses this path so downloaded artifacts can be streamed instead of unnecessarily buffered.
\n
The CLI has also progressively moved GitHub requests, metadata lookups, health checks, and downloads away from external curl, wget, and PowerShell commands toward vix::requests.
\n
This is intentionally not a rule that every appearance of curl must disappear. RunCommand still keeps its HTTP URI passthrough through curl, where that behavior is part of the command's existing semantics.
\n
The goal is not to remove a tool for ideological reasons. The goal is to stop depending on an external process where Vix already owns the HTTP operation itself.
\n
SDKs: users should pay for the capabilities they use
\n
A dependency that exists only because a Vix module needs it internally should not automatically become a system administration problem for every Vix user.
\n
This release moves the SDK further in that direction.
\n
SDK packaging is now driven by the selected profile rather than by modules that happen to be present in the CLI build. The contents of an SDK should describe the capabilities exported to its consumers, not the accidental shape of the machine that produced it.
\n
SDK archives also no longer contain a second vix executable. The CLI and the SDK are related parts of Vix, but an SDK archive should not silently become another CLI distribution channel.
\n
Profile metadata now follows the targets and headers that are actually exported to consumers.
\n
Internal dependencies are becoming Vix-owned dependencies
\n
Vix now bundles several dependencies that exist solely to implement Vix modules:
\n
\n
nlohmann-json
\n
fmt
\n
spdlog
\n
SQLite
\n
zlib
\n
Brotli
\n
\n
Their relevant headers and libraries can travel with the SDK capabilities that require them.
\n
This reduces machine-level prerequisites and, more importantly, makes the dependency contract more accurate. A consumer of vix::json should not need to understand how Vix internally obtains its JSON implementation. A consumer of compression support should not have to reconstruct the build environment used by the Vix repository.
\n
The installed package contract was tightened so internal build targets and host-specific library paths do not leak into external consumers.
\n
This work exposed an important distinction between two kinds of dependencies.
\n
Some dependencies are implementation details that Vix can reasonably own and distribute. Others are genuine platform capabilities.
\n
OpenSSL remains in the second category for profiles that actually export OpenSSL-dependent functionality. Core server TLS is opt-in, so a user who does not select that capability should not inherit its cost.
\n
That is the broader rule behind the SDK work:
\n
\n
A capability that is not used should not impose a dependency.
\n
\n
A more accurate public dependency graph
\n
The SDK contract was also cleaned up in several smaller but important places.
\n
curl and wget are no longer generic SDK prerequisites.
\n
Reply is now a public dependency of Note instead of Note carrying a second embedded implementation of the same functionality.
\n
The all profile includes the public tests module together with its aggregate header, so the name of the profile better matches what the SDK actually exposes.
\n
These changes are not individually large features, but together they make the installed SDK behave more like a product with a deliberate dependency model and less like a copy of the source-tree build environment.
\n
Mobile: integrate with the platform instead of replacing it
\n
Supporting Android and iOS does not require pretending that Gradle and Xcode do not exist.
\n
vix::ui now includes Android and iOS project generation and build support through a shared mobile application model.
\n
On Android, generated projects use the native Gradle and WebView stack.
\n
On iOS, generated projects use Xcode and WKWebView.
\n
The CLI exposes corresponding mobile initialization, build, and run commands, while the UI module remains responsible for project generation and the mobile application model.
\n
The important part is the boundary.
\n
Vix provides a common entry point and a consistent project-level experience, but the platform toolchains still do the work they are designed to do. Android builds are still Android builds. iOS builds are still Xcode builds.
\n
The generated projects are validated against those native environments, including Gradle and emulator workflows for Android and Xcode simulator builds on macOS.
\n
This is the direction Vix wants for platform support in general: provide a simpler and more coherent interface without erasing the platform underneath it.
\n
An abstraction is useful when it removes accidental complexity. It becomes harmful when using it requires pretending the underlying system no longer exists.
\n
Installed SDKs are now part of the tested contract
\n
A source tree compiling successfully is not enough to prove that an SDK is usable.
\n
The consumer never receives the Vix repository exactly as the Vix developers see it. The consumer receives installed headers, exported CMake targets, libraries, transitive requirements, and profile metadata.
\n
v2.9.0 expands release validation around that reality.
\n
SDK release checks now exercise installed artifacts and external consumer projects. They verify profile-specific capabilities, bundled dependency ownership, exported targets, public headers, and the behavior of projects that consume Vix from outside the source checkout.
\n
This work caught several classes of issue that a monorepo build can hide: dependencies accidentally satisfied by the source tree, exported targets carrying the wrong usage requirements, platform-specific linkage contracts, and installed headers depending on information that was available only during the original build.
\n
The packaged SDK is therefore becoming a first-class contract of Vix, not merely the by-product of a successful repository build.
\n
Smaller boundaries, stronger guarantees
\n
Many of the changes in v2.9.0 come from the same observation: complexity grows when two layers both believe they own the same responsibility.
\n
If Vix and Ninja both maintain the incremental compilation graph, one of them is doing unnecessary work.
\n
If Vix resolves a project dependency but the build system still has to rediscover where it came from and what exact revision was selected, ownership is unclear.
\n
If Vix bundles an implementation dependency but the consumer must still install and configure that same dependency independently, ownership is unclear.
\n
If an API is called asynchronous but part of its internal path blocks, its abstraction and its behavior disagree.
\n
If a mobile abstraction can work only by replacing the native platform, it eventually has to reimplement an entire ecosystem.
\n
v2.9.0 reduces those overlaps.
\n
Vix still does a lot, but the goal is not for Vix to own every part of the machine. The goal is for Vix to own the parts where it can provide a simpler, more reliable programming model, and compose correctly with the parts that already have a clear owner.
\n
What's next: Vix 3
\n
v2.9.0 closes an important chapter for Vix 2.
\n
Many of the changes in this release came from looking again at decisions that were reasonable when Vix was smaller, but became harder to justify as the project grew. The duplicated build work, dependency ownership, SDK boundaries, and the relationship between Vix abstractions and native platforms are all examples of lessons that will influence the next major version.
\n
The next step is Vix 3.
\n
Vix 3 is not intended to be a larger collection of modules or another layer of abstractions. It is an opportunity to revisit the foundations of Vix with the implementation experience gained from Vix 2.
\n
The goal is to reduce the number of concepts users need to understand, make the remaining concepts more composable, and move complexity into places where Vix can own it reliably.
\n
That means questioning assumptions that have accumulated over time: how projects describe what they need, how dependencies are owned and distributed, where the boundary between Vix and the C++ toolchain should live, and which parts of common C++ development can be made simpler without hiding the language or the machine.
\n
Some of the work in v2.9.0 already points in that direction.
\n
The build system now has clearer ownership boundaries. vix install separates dependency intent from reproducible resolution and can integrate those dependencies into existing CMake projects. SDK dependencies are becoming capabilities rather than machine setup instructions. Installed artifacts are treated as part of the public contract. Platform integrations preserve the native systems underneath them instead of trying to replace them.
\n
Vix 3 will continue from those principles.
\n
Its design is still being worked out, and early ideas should not become promises before they have been properly tested. The objective is not to add features for the sake of a major version number.
\n
It is to take what Vix has taught us so far and use it to build a smaller, clearer, and more durable foundation for what comes next.
\n
Summary
\n
Vix v2.9.0 improves five major areas:
\n
\n
the ordinary build path does less duplicated work and leaves incremental execution to CMake and Ninja
\n
vix install can manage reproducible Git dependencies for existing CMake projects through vix.app and vix.lock
\n
vix::requests has a stronger fully asynchronous path, connection reuse, and streaming response support
\n
SDKs are more self-contained and more faithful to the capabilities users actually select
\n
vix::ui can generate and drive practical Android and iOS projects while preserving native toolchains
\n
\n
The release also strengthens the installed SDK as a tested public contract rather than treating installation as the last step after a source-tree build succeeds.
\n
More broadly, v2.9.0 is less about making Vix own more of the system and more about making it own the right parts of the system.
\n
That direction will continue into Vix 3.
\n';
+const v2_9_0 = {
+ html
+};
+export {
+ v2_9_0 as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-CoPoSnqe.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-CoPoSnqe.js
new file mode 100644
index 000000000..48d7ff4c2
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-CoPoSnqe.js
@@ -0,0 +1,8 @@
+const html = '
vix.app
\n
Technical notes about vix.app, the simple manifest used to describe C++ applications without exposing users directly to CMake complexity.
This distinction is the foundation of correct build planning.
\n
If Vix confuses these two paths, the build may still work in small cases, but other systems can break:
\n
target detection\nbuild directories\nsnapshots\nartifact cache\nwatch mode\nexport paths\ndiagnostics\nvix run executable lookup
So vix.app requires a more explicit build plan.
\n
What build planning means
\n
Build planning is the phase where Vix decides:
\n
which project is being built\nwhich preset is active\nwhere the build directory is\nwhich source directory CMake should configure\nwhich target should be built\nwhich logs should be written\nwhether reconfigure is needed\nwhich cache state applies\nwhich executable should be resolved after build
It is the bridge between project resolution and build execution.
\n
Project resolution answers:
\n
What kind of project is this?
Build planning answers:
\n
How should this project be built?
The old simple assumption
\n
The old assumption was:
\n
plan.projectDir is the project
That works when:
\n
plan.projectDir/CMakeLists.txt
exists.
\n
Then Vix can configure with:
\n
cmake -S plan.projectDir -B plan.buildDir
The default target can be guessed from:
\n
plan.projectDir.filename()
The executable can be searched by that name.
\n
For a normal CMake project, this is acceptable.
\n
Why that breaks with vix.app
\n
For a vix.app project, the real project root contains:
\n
vix.app\nsrc/\ninclude/\nassets/
But it does not contain:
\n
CMakeLists.txt
Vix generates that file under:
\n
.vix/generated/app/CMakeLists.txt
So if the build plan stores only one projectDir, there are two bad choices.
\n
Bad choice 1: projectDir is the user project
\n
If:
\n
plan.projectDir = myapp/
then CMake configure would try:
\n
cmake -S myapp -B myapp/build-ninja
But myapp/ has no CMakeLists.txt.
\n
The configure step fails.
\n
Bad choice 2: projectDir is the generated CMake directory
vix.app\n -> BuildGraph\n -> ObjectCache\n -> Scheduler\n -> Link
This is possible because vix.app is declarative and limited.
\n
Vix does not have to interpret arbitrary CMake logic.
\n
It can directly create build tasks.
\n
Why native planning matters
\n
CMake is powerful, but it has overhead:
\n
configure step\ngenerate step\nbuild system files\ncache state\nindirection through generated rules
For many projects, this is acceptable.
\n
But for simple vix.app projects, Vix can eventually avoid some of that overhead.
\n
The goal is not to compile C++ magically faster.
\n
The goal is to avoid unnecessary work:
\n
do not reconfigure when inputs are unchanged\ndo not regenerate when manifest is unchanged\ndo not recompile clean objects\ndo not relink unchanged targets\nrestore cached artifacts when valid
Compatibility path vs fast path
\n
The clean long-term model is:
\n
CMakeLists.txt -> compatibility path\nvix.app -> fast path
The compatibility path keeps existing projects working.
\n
The fast path lets Vix optimize projects it understands directly.
\n
This split is more realistic than trying to replace CMake for every C++ project.
\n
vix build with CMake projects
\n
For a normal CMake project, planning stays close to the existing model:
1. userProjectDir points to the real project root.\n2. cmakeSourceDir points to .vix/generated/app.\n3. buildDir is under userProjectDir.\n4. defaultTargetName equals manifest.name.\n5. cmake -S uses cmakeSourceDir.\n6. cmake --build uses defaultTargetName when no target is provided.\n7. snapshots use userProjectDir.\n8. exports use userProjectDir.\n9. watch mode uses userProjectDir.\n10. diagnostics distinguish generated files from user files.
Why this matters
\n
Build planning is not only about making the current generated CMake path work.
\n
It is also preparing Vix for a native build engine.
\n
If the plan keeps project identity clean, then Vix can later switch a vix.app project from:
\n
generated CMake execution
to:
\n
native BuildGraph execution
without changing the user-facing manifest.
\n
The user still writes:
\n
vix.app
Only the execution engine changes.
\n
Conclusion
\n
vix.app forced Vix to make build planning more precise.
\n
A generated project has two important paths:
\n
the user project directory\nthe generated CMake source directory
It also has a target name that comes from the manifest, not from the folder name.
\n
Keeping these values separate makes vix build more correct today.
\n
It also creates the foundation for a faster native build path later.
\n
vix.app starts as generated CMake.\nvix.app can become native BuildGraph input.\nThe build plan is the bridge between both.
';
+const vixAppBuildPlanning = {
+ html
+};
+export {
+ vixAppBuildPlanning as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-generated-cmake-CDiZf8Js.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-generated-cmake-CDiZf8Js.js
new file mode 100644
index 000000000..67df8baa6
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-generated-cmake-CDiZf8Js.js
@@ -0,0 +1,8 @@
+const html = '
vix.app Generated CMake
\n
vix.app is the user-facing project description.
\n
CMake is the compatibility layer underneath.
\n
The current implementation works like this:
\n
vix.app\n -> parse manifest\n -> validate manifest\n -> generate .vix/generated/app/CMakeLists.txt\n -> configure with CMake\n -> build with CMake/Ninja
The generated CMake file is not meant to be edited by the user.
\n
It is an implementation detail that lets Vix support a simpler project format without breaking compatibility with the C++ ecosystem.
The exact generated command may differ, but the behavior is:
\n
resources are copied next to the built target after build
Why generated CMake is readable
\n
The generated CMake should be readable.
\n
Even though users should not edit it, readability matters for debugging.
\n
A readable generated file helps engineers understand:
\n
what Vix parsed\nwhat Vix generated\nwhat CMake is configuring\nwhy a package is found or not found\nwhy a target links or does not link\nwhere resources are copied
Generated code is still engineering output.
\n
It should not be treated as a black box.
\n
Debugging generated CMake
\n
If a vix.app build fails, inspect:
\n
.vix/generated/app/CMakeLists.txt
Then run:
\n
vix build -v
or:
\n
vix build --cmake-verbose
You can also pass extra CMake arguments after --:
\n
vix build -- -DCMAKE_PREFIX_PATH=/path/to/prefix
This is useful for packages installed in custom locations.
CMake should not be the first tool to discover that src/main.cpp does not exist.
\n
CMake errors still happen
\n
Some errors can only happen at configure or build time.
\n
Examples:
\n
package not found\nimported target not found\ncompiler flag not supported\nlinker flag not supported\nsymbol not found\nduplicate main()\nundefined reference
These are normal build errors.
\n
Vix can improve diagnostics, but they still originate from the compiler, linker, or CMake.
\n
Example: package found but not linked
\n
Input:
\n
packages = [\n fmt:REQUIRED,\n]
Generated CMake finds fmt, but no link is emitted.
But that would turn the generated file into the source of truth.
\n
That is not the goal.
\n
The source of truth should remain:
\n
vix.app
The generated CMake is disposable.
\n
That allows Vix to improve the generator without forcing users to maintain generated build files.
\n
Generated CMake and future native builds
\n
The generated CMake layer is the current compatibility path.
\n
It does not have to be the final build path.
\n
Because vix.app is structured, Vix can later build directly from it:
\n
vix.app\n -> native BuildGraph\n -> ObjectCache\n -> Scheduler\n -> Link
In that future model, generated CMake may still exist as:
\n
debug output\nfallback path\ncompatibility mode\nexport format
But the hot path for simple projects could become native.
\n
Why this matters
\n
Arbitrary CMake is hard to optimize because CMake is a full language.
\n
Vix has to ask CMake what the build graph is.
\n
But vix.app is declarative and narrow.
\n
Vix can understand it directly.
\n
That means Vix can eventually answer questions like:
\n
Which source files belong to this target?\nWhich include directories affect compilation?\nWhich definitions changed?\nWhich object files can be reused?\nDoes this target need to link again?\nWhich resources need copying?
This is the foundation for a faster build path.
\n
Generated CMake as a bridge
\n
The current design is a bridge.
\n
It gives users a small manifest today.
\n
It keeps CMake compatibility today.
\n
It prepares Vix for native build execution later.
\n
That is why generated CMake exists.
\n
It is not the final vision.
\n
It is the safe compatibility layer.
\n
Common debugging checklist
\n
When debugging a generated CMake project:
\n
1. Check vix.app first.\n2. Check .vix/generated/app/CMakeLists.txt.\n3. Check that sources were resolved correctly.\n4. Check include directories.\n5. Check packages.\n6. Check links.\n7. Check output_dir.\n8. Check resource copy commands.\n9. Run vix build -v.\n10. Use --cmake-verbose if configure output is needed.
What should not be generated
\n
The generator should not try to invent complex logic.
\n
It should not guess:
\n
which imported targets to link\nwhich optional packages to use\nhow to fetch dependencies\nhow to generate sources\nhow to install packages\nhow to run CTest
Those belong in explicit user configuration or full CMake.
\n
The generator should be powerful, but not magical.
\n
Conclusion
\n
Generated CMake is the bridge between vix.app and the existing C++ build ecosystem.
\n
The user writes a small manifest.
\n
Vix validates it.
\n
Vix generates a normal CMake project internally.
\n
CMake and Ninja build it.
\n
The generated file remains internal and disposable.
That is the engineering role of generated CMake in vix.app.
\n';
+const vixAppGeneratedCmake = {
+ html
+};
+export {
+ vixAppGeneratedCmake as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-internal-modules-DFT4W2eL.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-internal-modules-DFT4W2eL.js
new file mode 100644
index 000000000..d3cdafe52
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-internal-modules-DFT4W2eL.js
@@ -0,0 +1,8 @@
+const html = '
vix.app Internal Modules
\n
vix.app can describe internal application modules.\nThese modules are not external dependencies.\nThey are parts of the application itself.\nThe goal is simple:
As a C++ application grows, putting everything into one source tree becomes hard to maintain.\nA backend application may quickly need separated areas such as:
\n
\n
users
\n
auth
\n
billing
\n
orders
\n
notifications
\n
storage
\n
\n
Without a module structure, the project can become a flat collection of headers and source files.\nWithout build automation, every new module also requires manual CMake edits.\nThat creates friction.\nA developer should be able to create a module, declare it in the app, and build.
\n
Internal modules
\n
Internal modules are created with:
\n
vix modules add User
This creates a module under:
\n
modules/User/
The module has its own public header and implementation file.\nConceptually:
the app target depends on the internal module User
The generated build links the module into the application target.
\n
Field separation
\n
vix.app keeps different concepts separate.
\n
modules internal application modules\ndeps external packages from the Vix Registry\npackages system or CMake packages resolved with find_package(...)\nlinks raw CMake targets or libraries linked manually
This separation is important.\nA module is code inside the current application.\nA registry dependency is external package code.\nA package is a CMake discovery rule.\nA link is a manual target-level link instruction.\nThe manifest stays explicit.
\n
Example backend app
\n
A backend app can use internal modules for application features:
This makes the app structure visible directly in the manifest.\nThe reader can see that the app has internal modules for:
\n
\n
User
\n
Auth
\n
Billing
\n
\n
without opening the generated CMake file.
\n
Build flow
\n
The internal module flow is:
\n
vix modules add User\n -> modules/User/\n -> modules/User/CMakeLists.txt\n\nvix.app\n -> modules = [ User ]\n\nvix build\n -> generate .vix/generated/app/CMakeLists.txt\n -> include cmake/vix_modules.cmake\n -> link api with api::User\n -> build with CMake/Ninja
The user works with:
\n
\n
vix modules
\n
vix.app
\n
vix build
\n
\n
Vix handles the generated CMake layer.
\n
Module targets
\n
A module gets a canonical CMake alias based on the app name.\nFor an app named:
\n
name = api
and a module named:
\n
User
the expected module target is:
\n
api::User
So this manifest:
\n
name = api\n\nmodules = [\n User,\n]
is conceptually linked as:
\n
target_link_libraries(api PRIVATE api::User)
The user does not write this manually in a vix.app project.
\n
Why the app name matters
\n
The app name is used as the project namespace for internal modules.\nExample:
\n
name = blog\n\nmodules = [\n User,\n]
Expected module alias:
\n
blog::User
Another app:
\n
name = api\n\nmodules = [\n User,\n]
Expected module alias:
\n
api::User
This keeps module targets local to the application.\nIt avoids generic target names like:
\n
User
which could conflict with other libraries or modules.
\n
vix modules init
\n
Before adding modules, a project can initialize the module layout:
\n
vix modules init
For a vix.app project, Vix does not patch a root CMakeLists.txt.\nThere is no user-maintained root CMake file.
It does not automatically add it to vix.app.\nThat is intentional.\nCreating a module and using a module are different actions.\nA project may create a module that is not linked yet.\nA module may be experimental.\nA module may be used later.\nThe manifest should clearly show which modules the app target actually uses.\nThat is why the user declares:
\n
modules = [\n User,\n]
Generated module loading
\n
The generated CMake includes the module loader from the real project directory:
The public header is what other app code can include:
\n
#include <User/api.hpp>
The implementation file stays inside the module.\nThis encourages a clear boundary.\nThe application can depend on the module API without knowing the internal implementation layout.
\n
Module safety
\n
Internal modules should follow safe boundaries.\nA public header should not include private implementation files.\nA module that includes another module should declare that relationship in its module CMake target.\nThis prevents hidden coupling.\nIt also makes the build graph easier to understand.\nA module system should not only create folders.\nIt should help preserve architecture.
If a module is declared in vix.app but does not exist, the build should fail clearly.
\n
Example:
\n
modules = [\n User,\n]
But the module folder is missing:
\n
modules/User/
The error should explain that the module declared in vix.app is not available.\nThis is better than a generic CMake target error.\nThe user should know which manifest entry caused the problem.
\n
Modules and registry deps
\n
Internal modules and registry dependencies can be used together.\nExample:
User local application module\ngk/email external registry package
The generated build links both into the app target.\nBut they remain different concepts in the manifest.
\n
Why this is app-first
\n
The app should describe its architecture.\nWith modules, the manifest can say:
\n
this application is composed of these internal units
That is more meaningful than only listing source files.\nSource files are low-level build input.\nModules are higher-level application structure.\nThis is why modules belongs in vix.app.
\n
Why this matters for large apps
\n
As applications grow, architecture becomes more important than build commands.\nA backend project may have:
\n
\n
presentation
\n
application
\n
domain
\n
infrastructure
\n
support
\n
\n
Inside those areas, internal modules can represent clear feature boundaries.
This gives the project a visible shape.\nThe manifest becomes more than a file list.\nIt becomes a small architecture map.
\n
Good developer experience
\n
The module workflow should feel direct:
\n
vix modules init\nvix modules add User
Then edit:
\n
modules = [\n User,\n]
Then:
\n
vix build
The output should avoid internal build jargon when it is not needed.\nFor example, in a vix.app project, vix modules add User should not tell the user to edit target_link_libraries(...).\nIt should tell the user to add the module in vix.app.
\n
What stays explicit
\n
Vix does not silently link every module in modules/.\nThe user decides what the app uses.\nThis avoids accidental coupling.\nIt also allows modules to exist without being part of the current app target.\nThe manifest remains explicit:
\n
modules = [\n User,\n Billing,\n]
Only declared modules are linked.
\n
Current design boundary
\n
Internal modules currently use generated CMake underneath.
This is a compatibility layer.\nLater, Vix can use the same manifest data to build modules through a native build graph.\nThe important part is that vix.app now has a structured way to describe internal architecture.
\n
Conclusion
\n
vix.app can now work with internal application modules.\nThe developer can create a module with:
\n
vix modules add User
Then declare it in the manifest:
\n
modules = [\n User,\n]
Vix loads the module system.\nVix links the module into the app target.\nThe user does not maintain generated CMake.\nThis keeps the project simple at the surface and modular underneath.
\n';
+const vixAppInternalModules = {
+ html
+};
+export {
+ vixAppInternalModules as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-manifest-design-BHjfrKWi.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-manifest-design-BHjfrKWi.js
new file mode 100644
index 000000000..b7bcf926e
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-manifest-design-BHjfrKWi.js
@@ -0,0 +1,8 @@
+const html = '
vix.app Manifest Design
\n
vix.app is designed around one idea:
\n
a C++ project should be describable before it becomes a build-system program
The manifest is intentionally small.
\n
It does not try to expose every CMake feature.
\n
It describes the common structure of a C++ target in a way that Vix can parse, validate, generate, and later optimize.
\n
The design problem
\n
A C++ project usually needs a build description.
\n
Even for a small executable, the build system needs to know:
How are targets linked together?\nHow are public and private includes represented?\nHow are per-target packages handled?\nHow are tests discovered?\nHow are examples grouped?\nHow are install rules expressed?\nHow is ordering represented?
At that point, the manifest starts becoming a second CMake.
That is the main reason the manifest exists as a separate layer.
\n
vix.app is not a second CMake.\nIt is a structured target description for Vix.
';
+const vixAppManifestDesign = {
+ html
+};
+export {
+ vixAppManifestDesign as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-project-resolution-BAZJoutx.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-project-resolution-BAZJoutx.js
new file mode 100644
index 000000000..e54ee49a6
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-project-resolution-BAZJoutx.js
@@ -0,0 +1,8 @@
+const html = '
vix.app Project Resolution
\n
vix.app project resolution is the step where Vix decides what kind of project it is working with.
\n
Before Vix can build or run anything, it needs to answer a few questions:
\n
Where is the project root?\nIs this a CMake project?\nIs this a vix.app project?\nWhat source directory should CMake use?\nWhat target name should be built?\nWhere should build directories be created?
This resolution step is small, but it is important.
\n
If project resolution is wrong, the build system can use the wrong directory, the wrong target name, or the wrong generated CMake source.
\n
The resolution rule
\n
Vix uses this rule:
\n
1. If CMakeLists.txt exists, use CMakeLists.txt.\n2. Otherwise, if vix.app exists, use vix.app.
This keeps existing CMake projects safe.
\n
A project like this is resolved as a CMake project:
So clean project resolution is not only about generated CMake.
\n
It is also preparation for a native build engine.
\n
The clean architecture
\n
A clean architecture has three layers:
\n
Project resolution\n decides what project this is\n\nBuild planning\n decides what to configure, build, cache, and run\n\nExecution\n runs CMake, Ninja, native tasks, or the final executable
vix.app should enter the system at the resolution layer.
\n
It should not be patched into every command separately.
\n
Practical rule for engineers
\n
When changing Vix project resolution, keep this rule in mind:
\n
CMake source directory is not always the user project directory.\nTarget name is not always the project folder name.
This is the core lesson from vix.app.
\n
For normal CMake projects, those values often look the same.
\n
For generated projects, they are different.
\n
Conclusion
\n
vix.app project resolution is about keeping identities separate.
\n
A vix.app project has:
\n
a real user project directory\na generated CMake source directory\na manifest-defined target name\na generated flag
CMake projects remain the full-control path.
\n
vix.app projects become the simple path.
\n
The resolver connects both models through one consistent result.
\n
That consistency lets vix build, vix run, diagnostics, caching, and future native builds all reason about the project the same way.
\n';
+const vixAppProjectResolution = {
+ html
+};
+export {
+ vixAppProjectResolution as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-registry-dependencies-B4gNIExS.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-registry-dependencies-B4gNIExS.js
new file mode 100644
index 000000000..4bbc8022f
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-registry-dependencies-B4gNIExS.js
@@ -0,0 +1,8 @@
+const html = '
vix.app Registry Dependencies
\n
vix.app can now declare dependencies from the Vix Registry directly in the application manifest.
\n
The application stays simple.\nThe dependency system stays explicit.\nThe generated build keeps the native C++ integration underneath.
\n
The problem
\n
A C++ application often needs small external libraries.\nWithout a higher-level manifest, the user usually has to manage several things manually:
\n
where the dependency is installed\nwhich include directory it exposes\nwhich CMake target it exports\nwhich transitive dependencies it needs\nhow the package is linked to the app target
That is too much wiring for simple application projects.\nFor vix.app, the user should describe the application.\nThey should not have to maintain generated CMake glue by hand.
the application depends on the Vix Registry package gk/email
The user still installs dependencies with:
\n
vix install
Then builds normally:
\n
vix build
Field separation
\n
vix.app now has several dependency-related fields, but they do not mean the same thing.
\n
modules internal application modules created with vix modules\ndeps external packages from the Vix Registry\npackages system or CMake packages resolved with find_package(...)\nlinks raw CMake targets or libraries linked manually
This separation matters.\nA module is application code.\nA registry dependency is external package code.\nA package is a CMake discovery rule.\nA link is a target-level link instruction.\nKeeping these concepts separate makes the manifest predictable.
\n
Example with modules and deps
\n
A backend app can use both internal modules and registry dependencies:
vix.app declares the dependency.\nvix install installs the resolved packages.\nThe generated vix_deps.cmake exposes CMake targets.\nThe generated application CMake includes that file and links the declared dependencies.
\n
Why vix install still matters
\n
vix.app is declarative.
\n
It does not fetch packages by itself.\nDependency installation remains explicit:
\n
vix install
This keeps the build reproducible.\nIt also keeps dependency installation separate from normal compilation.\nA missing dependency integration file gives a direct error:
\n
vix.app dependencies are declared, but .vix/vix_deps.cmake was not found.\nRun: vix install
That is better than letting CMake fail later with a confusing missing include or missing target.
\n
Generated CMake integration
\n
When deps is not empty, the generated application CMake includes:
The exact generated target may use an internal safe name and expose the public alias:
\n
gk::email
The important point is that the application can link the dependency by its canonical registry target.
\n
Packages with CMakeLists.txt
\n
Some packages include their own CMakeLists.txt.\nWhen the package is not header-only, Vix can load it with add_subdirectory(...).\nBut header-only packages are handled differently.\nEven if a header-only package contains a CMakeLists.txt, Vix can safely expose it as an interface dependency.\nThis avoids entering package CMake code that may be written for standalone builds.
\n
Transitive dependencies
\n
A registry package may depend on other registry packages.
\n
Example:
\n
gk/email\n -> gk/jwt\n -> gaspardkirira/hmac
The lock file contains the full resolved dependency graph.\nvix install installs all resolved dependencies and generates CMake integration for each one.\nThat means the final project can have:
\n
gk::email\ngk::jwt\ngaspardkirira::hmac
available from .vix/vix_deps.cmake.\nThe app manifest only needs to declare what the app uses directly:
\n
deps = [\n gk/email,\n]
The transitive packages are still installed and made available by the lock.
\n
Why target fallback matters
\n
A dependency can be installed correctly but still fail to link if no expected CMake target exists.
\n
For example:
\n
dependency: gk/email\nexpected target: gk::email
Vix solves this by ensuring a stable target exists for header-only packages.\nThat makes this work:
\n
deps = [\n gk/email,\n]
without asking the user to know the internal build details of gk/email.
\n
Better errors
\n
The generated CMake emits a stable Vix error marker when a declared dependency is not linkable.\nInstead of a generic CMake error like:
\n
CMake configure failed
Vix can show:
\n
error: vix.app dependency is not linkable\ndependency: gk/email\ntarget: gk::email
This is important.\nThe user should know that the dependency is installed, but the expected build target is missing.\nThat is a Vix dependency integration problem, not a random CMake failure.
\n
vix install output for vix.app projects
\n
For a classic CMake project, vix install can tell the user to add:
The app builds through the generated CMake project.\nThe application manifest stays the source of truth.
\n
Why this belongs in vix.app
\n
The goal of vix.app is not to hide C++.\nThe goal is to remove repetitive project wiring.\nDependency declarations are application-level information.\nThey belong in the application manifest.\nThe user should be able to read one file and understand:
\n
\n
what this app builds
\n
which sources it uses
\n
which internal modules it has
\n
which registry packages it depends on
\n
which system packages it needs
\n
which raw targets it links
\n
\n
That is the value of vix.app.
\n
What stays explicit
\n
vix.app does not remove explicitness.
\n
It still keeps these concepts separate:
\n
\n
deps for Vix Registry packages
\n
packages for CMake find_package(...)
\n
links for manual CMake targets
\n
modules for internal application modules
\n
\n
This avoids hidden magic.
\n
If a dependency is from the Vix Registry, use deps.\nIf it is a system dependency, use packages.\nIf a target must be linked manually, use links.\nIf it is application code, use modules.
\n
Current design boundary
\n
The current registry dependency integration still uses CMake underneath.
This is still a compatibility layer.\nLater, Vix can use the same structured manifest and lockfile to build directly from a native build graph.\nThe important part is that the manifest is now structured enough to support both paths.
\n
Conclusion
\n
vix.app can now describe registry dependencies directly.
\n
The developer writes:
\n
deps = [\n gk/email,\n]
Vix installs the dependency graph.\nVix generates the CMake integration.\nVix links the declared dependency into the app target.\nThe user does not edit generated CMake.\nThis keeps the application manifest simple while still producing a normal native C++ build.
\n';
+const vixAppRegistryDependencies = {
+ html
+};
+export {
+ vixAppRegistryDependencies as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-tests-and-examples-9qHCWkhj.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-tests-and-examples-9qHCWkhj.js
new file mode 100644
index 000000000..5ff6c4eec
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-app-tests-and-examples-9qHCWkhj.js
@@ -0,0 +1,8 @@
+const html = '
vix.app Tests and Examples
\n
vix.app is intentionally designed around one rule:
\n
one vix.app = one target
That rule also affects how tests and examples should be organized.
\n
Instead of adding a complex multi-target syntax to one manifest, the recommended approach is to use separate manifests:
#pragma once\n\nnamespace myapp\n{\n int add(int a, int b);\n int run();\n}
src/app.cpp:
\n
#include <vix.hpp>\n#include <myapp/app.hpp>\n\nnamespace myapp\n{\n int add(int a, int b)\n {\n return a + b;\n }\n\n int run()\n {\n vix::print("myapp running");\n return 0;\n }\n}
root/vix.app -> main target\ntests/vix.app -> test executable\nexamples/name/vix.app -> example executable
Use explicit sources.
\n
Use relative paths carefully.
\n
Do not include main.cpp in test executables.
\n
Use CMake when the test system becomes complex.
\n
vix.app is strongest when every manifest describes one clear target.
\n';
+const vixAppTestsAndExamples = {
+ html
+};
+export {
+ vixAppTestsAndExamples as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-artifact-cache-design-Di4r3UOh.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-artifact-cache-design-Di4r3UOh.js
new file mode 100644
index 000000000..54b546ab0
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-artifact-cache-design-Di4r3UOh.js
@@ -0,0 +1,8 @@
+const html = '
vix Artifact Cache Design
\n
An object cache speeds up compilation at the source-file level.\nAn artifact cache works at a larger level.\nIt answers a different question:
\n
Have we already built this target, package, or binary with the same relevant inputs?
If the answer is yes, Vix can reuse the result instead of rebuilding it.\nThis is especially important for C++ because repeated builds often spend time not only compiling source files, but also rebuilding libraries, relinking executables, and rebuilding dependencies that did not really change.
\n
Object cache vs artifact cache
\n
The object cache works on individual compilation outputs.
Imagine a dependency that rarely changes.\nWithout an artifact cache, each project may rebuild it again.\nWith an artifact cache, Vix can build it once, store the result, and reuse it when the same inputs appear again.\nThis matters for:
\n
global packages\ncompiled dependencies\nCI builds\nclean builds\nlarge libraries\nrepeated local builds\ncross-project reuse
The goal is not to hide compilation.\nThe goal is to avoid rebuilding known outputs.
\n
The basic idea
\n
The basic artifact cache flow is:
\n
1. describe the artifact\n2. compute a fingerprint\n3. check the cache\n4. if hit, restore or reuse the artifact\n5. if miss, build normally\n6. store the result after success
A cache hit is only safe if the fingerprint is correct.
\n
Artifact identity
\n
An artifact needs a stable identity.\nFor example:
A compiled library built with GCC Debug is not the same as the same library built with Clang Release.\nThe artifact identity must include enough information to avoid invalid reuse.
\n
Fingerprint
\n
A fingerprint is a compact representation of build-relevant inputs.\nFor an artifact, the fingerprint can include:
The exact format can change.\nThe important part is explainability.\nVix should know what an artifact is and why it is valid.
\n
Artifact cache hit
\n
An artifact cache hit means Vix found a complete reusable output.\nExample:
\n
artifact cache hit: mathlib
Then Vix can reuse the cached artifact instead of rebuilding it.\nFor a package, that may mean adding a cached prefix to the build.\nFor a final target, that may mean restoring the binary or skipping the build.
\n
Artifact cache miss
\n
An artifact cache miss means no valid artifact was found.\nReasons can include:
\n
first build\nsource changed\ncompiler changed\nbuild type changed\ntarget triple changed\ndependency changed\nlink options changed\npackage version changed\ncache entry missing\ncache entry invalid
A miss should not be treated as an error.\nIt simply means Vix must build normally.
\n
Storing after build
\n
After a successful build, Vix can store the artifact.\nFor a library, store:
\n
library file\npublic headers if needed\nmetadata\ndependency information
For an executable, store:
\n
binary\nresources if needed\nmetadata
For a package prefix, store:
\n
include/\nlib/\nshare/\nmanifest.json
Storing should happen only after the build succeeds.
\n
No-op build acceleration
\n
A local artifact state can make no-op builds very fast.\nIf the current project inputs match the previous successful build state, Vix may avoid:
\n
configure\ncompile\nlink\ncopy
or at least avoid most of them.\nThe ideal no-op build is:
\n
nothing changed\nnothing to do\ndone
This is one of the places where Vix can feel much faster than traditional workflows.
\n
Clean build with warm artifact cache
\n
A clean build normally removes the build directory.
\n
rm -rf build-ninja
Without a cache, everything must rebuild.\nWith a warm artifact cache, Vix may restore or reuse:
The build directory is clean, but the global cache is not.\nThat can turn a clean build into a mostly restore operation.
\n
Artifact cache and object cache together
\n
The strongest model combines both caches.
\n
Artifact cache hit:\n reuse whole target or package\n\nArtifact cache miss:\n use object cache for individual compile tasks\n\nObject cache miss:\n compile source
This gives several layers of acceleration.\nVix should always try the largest safe reuse first.
\n
Layered cache strategy
\n
A layered strategy can look like this:
\n
1. Check local no-op state.\n2. Check artifact cache for target or package.\n3. Check object cache for compile tasks.\n4. Run compiler for remaining misses.\n5. Link only if needed.\n6. Store successful outputs.
This is how Vix can avoid repeated work at multiple levels.
\n
Relationship with BuildGraph
\n
The BuildGraph tells Vix what the target depends on.\nThe artifact cache tells Vix whether a larger output can be reused.\nThe graph helps compute the artifact fingerprint.\nFor example, a target artifact depends on:
If the artifact cache misses, the scheduler can still use object cache during compile tasks.
\n
Relationship with Link
\n
Linking can be expensive.\nEven if object files are cached, the final link can still take time.\nArtifact caching can help avoid relinking when the linked output is already known to be valid.\nA future link cache could store:
If resources are part of the final artifact, their content should be included in the artifact identity.\nIf a resource changes, the artifact should not be reused without updating the resource output.
\n
Artifact cache and vix.app
\n
vix.app is a good input for artifact caching because it is structured.
That makes it easier to compute a stable artifact fingerprint.\nFor arbitrary CMake projects, Vix may need to rely on generated build files and CMake state.\nFor vix.app, Vix can eventually compute more directly.
\n
Artifact cache and CMake projects
\n
For CMake projects, artifact caching should be conservative.\nCMake can contain arbitrary logic.\nSo Vix should base artifact decisions on generated outputs such as:
It should not try to guess what arbitrary CMake logic means.
\n
Artifact cache and packages
\n
Package artifacts are one of the best initial use cases.
\n
Why ?\nBecause packages often change less frequently than application source code.\nIf Vix can reuse compiled packages across projects, it can reduce a lot of repeated work.
\n
Example:
\n
project A builds package X\nproject B uses same package X\nproject B reuses cached compiled artifact
This is especially useful for local development and CI.
\n
Artifact cache and CI
\n
CI often starts from a clean workspace.\nThat makes artifact cache valuable.
\n
A CI system can restore:
\n
~/.vix/cache/build/
before building.
\n
Then Vix can reuse compiled dependencies or target artifacts when identities match.\nBut the cache key must account for:
So build type must be part of the artifact identity.
\n
Artifact cache and compiler
\n
Artifacts depend on the compiler.\nA static library built with one compiler may not be safe to reuse with another compiler.\nImportant compiler identity fields include:
A build cache stores executable code.\nIf artifacts come only from the local machine, the risk is lower.\nIf artifacts are shared remotely, Vix must treat them carefully.\nRemote artifacts need stronger integrity checks.
For a local-first build cache, start simple and safe.
\n
Remote artifact cache
\n
A future remote cache could let teams share compiled outputs.\nThat requires strict identity and trust rules.\nA remote artifact cache must know:
\n
who produced the artifact\nwhich compiler was used\nwhich source fingerprint was used\nwhether the artifact is trusted
This is powerful, but it should come after local cache correctness is solid.
\n
Artifact cache and native vix.app builds
\n
In the future native path:
\n
vix.app\n -> BuildGraph\n -> ObjectCache\n -> Scheduler\n -> Link
artifact cache can sit above the graph.\nBefore scheduling tasks, Vix can ask:
\n
Do I already have the final target artifact?
If yes, restore it.\nIf no, execute the graph.\nThis is the fastest path when safe.
\n
Artifact cache and generated CMake
\n
In the current path:
\n
vix.app -> generated CMake -> CMake/Ninja
Vix can still use artifact cache.\nIt can fingerprint the generated CMake, manifest, and build configuration.\nThen it can decide whether a previous artifact is still valid.\nThis makes artifact caching useful before native builds are complete.
\n
What artifact cache cannot solve
\n
Artifact cache cannot make every first build instant.\nIf Vix has never seen an artifact before, it must build it.\nIf inputs changed, it must rebuild.\nIf the compiler changed, old artifacts may be invalid.\nSo the promise is not:
\n
all builds are instant
The promise is:
\n
repeated builds avoid repeated work
That is realistic and valuable.
\n
Good first target
\n
The best first target for artifact caching is compiled package reuse.
\n
Why?
\n
packages are reused across projects\npackage source changes less often\npackage build cost can be high\ncache hits are easy to explain
Final executable caching can come later.\nPackage artifacts provide immediate value.
It does not need remote cache or perfect link caching on day one.
\n
Start with correctness and visibility.
\n
Later improvements
\n
Later improvements can include:
\n
final binary restore\nlink result cache\nremote artifact cache\ncache eviction policies\nartifact signing\nteam cache\nCI cache integration\nexplainable miss reasons\nnative vix.app integration
The system should grow in layers.
\n
Engineering principle
\n
The artifact cache should follow this principle:
\n
reuse large outputs only when their full build identity is known
That identity must include source, dependencies, compiler, linker, build type, target triple, and options.
\n
If identity is incomplete, the cache should miss.
\n
Conclusion
\n
The artifact cache is the coarse-grained cache layer in vix build.\nIt complements the object cache.\nObject cache avoids recompiling individual source files.\nArtifact cache avoids rebuilding larger outputs such as libraries, executables, and compiled packages.\nTogether with the BuildGraph, Scheduler, and future native vix.app path, artifact caching gives Vix a realistic path toward dramatically faster repeated C++ builds.\nThe goal is not magic.\nThe goal is disciplined reuse:
\n
same inputs\nsame build identity\nsame artifact\nreuse safely
';
+const vixArtifactCacheDesign = {
+ html
+};
+export {
+ vixArtifactCacheDesign as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-build-Ck9JqEiH.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-build-Ck9JqEiH.js
new file mode 100644
index 000000000..b1bfe469c
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-build-Ck9JqEiH.js
@@ -0,0 +1,8 @@
+const html = '
vix build
\n
Technical notes about how vix build configures, plans, caches, and executes native C++ builds.
\n';
+const vixBuild = {
+ html
+};
+export {
+ vixBuild as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-build-cmake-compatibility-DgnIboBj.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-build-cmake-compatibility-DgnIboBj.js
new file mode 100644
index 000000000..bcad1fb16
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-build-cmake-compatibility-DgnIboBj.js
@@ -0,0 +1,8 @@
+const html = '
vix build CMake Compatibility Path
\n
vix build does not try to remove CMake.
\n
CMake remains the compatibility path for C++ projects.
\n
That is intentional.
\n
C++ projects are not uniform. Some are small applications. Some are libraries. Some are monorepos. Some use generated sources, custom commands, package exports, install rules, CTest, toolchains, and platform-specific build logic.
\n
A build tool for C++ cannot ignore that reality.
\n
So Vix takes a layered approach:
\n
CMakeLists.txt -> compatibility path\nvix.app -> simple path\nfuture native -> fast path for projects Vix understands directly
The compatibility path keeps existing projects working.
\n
The simple path makes new projects easier to start.
\n
The future native path gives Vix room to become faster for vix.app projects.
\n
Why CMake remains important
\n
CMake is widely used because it solves hard C++ build problems.
This matters because a fast build system should not ask only:
\n
How do I build everything?
It should ask:
\n
What exactly changed?\nWhat depends on it?\nWhich tasks are dirty?\nWhich outputs can be restored from cache?\nWhich target did the user ask for?\nWhat can be skipped safely?
That is the purpose of the Vix build graph.
\n
Why a build graph exists
\n
A C++ build is naturally a graph.
\n
A source file produces an object file.
\n
An object file contributes to a library or executable.
The second step was to make the output more stable and less noisy.
+A no-op fast path should look like this:
+
Checking vix (dev)
+ ✔ Up to date in 0.30s
A graph target build should look like this:
+
Building vix (dev)
+ ✔ Graph target: vix
+ ✔ Up to date
+ ✔ Done
The output rules are now:
+
vix build
+ -> minimal user output
+
+vix build -v
+ -> detailed but still readable output
+
+VIX_LOG_LEVEL=debug vix build -v
+ -> internal graph/cache/build logs
Internal details should not pollute normal builds.
+Users should see what matters.
+Developers debugging Vix internals can still access the deeper logs.
+
3. Safer --fast
+
The --fast path is only useful if it is safe.
+It should never say Up to date unless the target is really up to date.
+The build state validation was strengthened to check:
+
+
project fingerprint
+
build signature
+
build target
+
preset
+
build type
+
compiler identity
+
target identity
+
project inputs
+
last binary path
+
last binary exists
+
last binary is executable
+
artifact root exists
+
+
Some values such as launcher, linker and CMake variables are already part of the build signature.
+The important rule is:
+
state hit is not enough
+the final binary must still exist
So if the last binary was deleted, Vix must fallback to the normal build path.
The last command must not return a false Up to date.
+
4. Build safety tests
+
The next step was adding a dedicated safety test script.
+The script covers the most fragile paths:
+
+
build target all
+
build target real
+
graph executor enabled
+
graph executor disabled
+
--fast state hit
+
--fast fallback
+
missing last binary
+
changed source file
+
changed header file
+
changed CMakeLists.txt
+
changed compiler flags
+
changed build target
+
+
The goal is regression protection.
+Every optimization must prove that it does not break correctness.
+The test script creates a small temporary CMake project, runs vix build in different modes, and checks the output behavior.
+
This gives Vix a safety net before adding more aggressive caching or native build execution.
+
5. Faster no-op builds without --fast
+
Before this step, the normal build path could still pay for:
+
+
scan project
+
load compile_commands.json
+
load build.ninja
+
load dependency files
+
propagate dirty state
+
+
even when nothing changed.
+The improvement was to allow a valid build state hit to return early even without --fast.
+That means:
+
vix build --build-target vix
can also become fast when the build state proves that nothing changed.
+The ideal no-op path becomes:
+
read build state
+snapshot project inputs
+compare signatures
+verify last binary
+return up to date
This turns the build state from a --fast-only feature into a general no-op optimization.
+
6. Explaining why Vix rebuilds
+
Speed is not the only goal.
+A build tool should also explain its decisions.
+The new --explain path is designed for this:
The first version uses the current graph and the previous graph to compare:
+
+
task existence
+
command hash
+
missing outputs
+
source changes
+
header changes
+
config changes
+
node state changes
+
+
This starts the foundation for a bigger feature:
+
+
Vix should not only rebuild. Vix should explain why it rebuilt.
+That is very important for large C++ projects.
+When a single header causes many files to rebuild, users should be able to see the reason.
+
+
7. Safer Ninja import
+
Vix imports build.ninja so it can understand the generated build graph.
+
The goal is not to blindly reimplement Ninja.
+The goal is to use Ninja metadata safely.
+The improved rules are:
The correction rule is more important than speed: if unsure, use CMake/Ninja.
+
8. Stronger ObjectCache
+
ObjectCache is responsible for avoiding unnecessary recompilation.
+The cache key must be strong enough to prevent wrong reuse.
+A compile cache key now depends on:
+
+
source content hash
+
dependency/header content hash
+
command hash
+
compiler identity
+
target triple
+
build fingerprint
+
build type
+
defines
+
include dirs
+
compile flags
+
+
The expected flow is:
+
for each compile task:
+ compute object cache key
+
+ if cache hit:
+ restore .o
+ restore .d
+ skip compiler
+
+ else:
+ compile
+ store .o
+ store .d
A key improvement is making the object cache survive build directory deletion.
+Instead of only living under the build directory, the object cache can live under:
simple features -> native Vix build path
+complex features -> generated CMake fallback
Vix already has:
+
+
AppManifest
+
AppManifest parser
+
AppProjectResolver
+
AppCMakeGenerator
+
+
So the native path should reuse the existing AppManifest.
+It should not create a second parser.
+The safe V1 supports simple executable projects.
+Complex features still fallback to generated CMake:
+
+
packages
+
resources
+
links
+
compile features
+
static libraries
+
shared libraries
+
+
This keeps compatibility while letting Vix start owning the native build path.
+
11. Better diagnostics
+
A faster build is not enough.
+When a build fails, the output should help the developer fix it quickly.
+The diagnostic improvements focus on:
+
+
compiler errors with code frame
+
warnings grouped
+
file + line + column
+
raw command hidden by default
+
raw command visible in debug
+
hint for missing headers
+
hint for linker errors
+
hint for unresolved targets
+
+
Expected style:
+
Build failed
+
+src/main.cpp:12:10
+ error: 'App' was not declared
+
+Hint:
+ Declare the symbol before use, include the right header,
+ or move the function definition above the call.
For missing headers:
+
Build failed
+
+src/main.cpp:2:10
+ error: fatal error: app.hpp: No such file or directory
+
+Hint:
+ Check that the header exists and that its directory is listed
+ in include_dirs, target_include_directories, or your compiler include paths.
Warnings should be grouped:
+
warning 3 compiler warnings
+ • src/main.cpp:10:9: warning: unused variable 'x'
+ • src/app.cpp:4:12: warning: unused function 'foo'
+ • src/db.cpp:8:5: warning: control reaches end of non-void function
Raw commands should stay hidden by default. Debug mode can show them:
+
VIX_LOG_LEVEL=debug vix build -v
This keeps normal output clean and makes internal debugging possible.
+
12. CI and official benchmarks
+
The last step was adding a reproducible way to prove the gains.
+The standard benchmark is:
if build state proves clean:
+ return up to date
+
+else if complete artifact exists:
+ restore target
+
+else if real target is graph-safe:
+ use Graph Executor
+
+else:
+ use CMake/Ninja
This creates a progressive build system.
+Each layer tries to solve the build earlier.
+If a layer cannot prove correctness, Vix falls back to the next safer layer.
+
Why this matters
+
C++ build tooling often forces users to choose between power and simplicity.
+
Vix is taking a different path:
+
+
keep CMake/Ninja compatibility
+
add fast paths where safe
+
add graph intelligence gradually
+
improve diagnostics
+
make common workflows simpler
+
+
This is not a rewrite of the C++ ecosystem.
+It is a practical build layer that improves the developer workflow step by step.
+
The principle
+
+
Vix should be fast when it can prove correctness.
+Vix should fallback when another tool is safer.
+
+
That principle applies to every part:
+
all target -> fallback
+ambiguous target -> fallback
+complex vix.app -> fallback
+missing binary -> fallback
+changed inputs -> rebuild
+valid no-op state -> return fast
This is how Vix can become faster without becoming fragile.
+
Conclusion
+
The latest vix build work turns the roadmap into a stronger build architecture.
+
Vix now has a clearer path toward:
+
+
fast no-op builds
+
safer target routing
+
better cache reuse
+
native vix.app execution
+
clearer diagnostics
+
reproducible benchmarks
+
+
The long-term direction is now visible:
+
CMake/Ninja -> for compatibility
+BuildGraph -> for intelligence
+ObjectCache -> for compile reuse
+ArtifactCache -> for target reuse
+vix.app -> for native simple builds
+diagnostics -> for developer experience
+CI/benchmarks -> for proof
This is the foundation of a modern C++ build workflow inside Vix.
+`;
+const vixBuildRoadmapExecution = {
+ html
+};
+export {
+ vixBuildRoadmapExecution as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-core-DZprlsQI.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-core-DZprlsQI.js
new file mode 100644
index 000000000..1aeb7a914
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-core-DZprlsQI.js
@@ -0,0 +1,8 @@
+const html = '
This shows that basic request construction is fast, while query parsing naturally adds more work.
\n
That is useful to know because request creation is part of the request-processing path.
\n
HTTP response results
\n
The HTTP response benchmarks measure construction, status helpers, headers, common response helpers, JSON/text responses, and HTTP string serialization.
Very small response construction benchmarks can produce extremely high ops/sec numbers because the measured operation is tiny.
\n
Those numbers are useful as guardrails, but they should be interpreted together with larger response benchmarks such as full HTTP string serialization.
\n
Session results
\n
The session benchmarks use an in-memory fake transport.
\n
This avoids external network noise while still testing a higher-level request-processing path.
Even if low-level router registration is fast, the app layer can still add overhead through route normalization, automatic OPTIONS routes, group prefixes, middleware helpers, and route records.
\n
Now that overhead is measurable.
\n
Why Release mode is required
\n
Benchmarks must be generated from a Release build.
\n
A dev/debug build is useful for development, debugging, and validating that everything compiles.
\n
But it is not useful for official performance numbers.
The exact output path is an implementation detail.
\n
The user-facing behavior should remain simple:
\n
vix run main.cpp
Script mode is not project mode
\n
Direct script mode is different from project mode.
\n
Script mode input:
\n
one source file
Project mode input:
\n
project root\nCMakeLists.txt or vix.app\ntarget name\nbuild directory
So this:
\n
vix run main.cpp
should not behave the same as:
\n
vix run
inside a project.
\n
An explicit source file means script mode.
\n
No source file means project mode.
\n
Minimal example
\n
main.cpp:
\n
#include <vix.hpp>\n\nint main()\n{\n vix::print("hello from Vix script mode");\n return 0;\n}
Run:
\n
vix run main.cpp
Expected output:
\n
hello from Vix script mode
The developer does not need to create:
\n
CMakeLists.txt\nvix.app\nbuild-ninja/
manually.
\n
What the runner needs to know
\n
Even for one file, Vix still needs build information.
\n
The direct script runner must decide:
\n
which compiler to use\nwhich C++ standard to use\nwhich include paths to use\nwhich libraries to link\nwhere to place outputs\nhow to pass runtime arguments\nhow to report compile errors
The command is simple, but the execution still needs structure.
\n
Compiler selection
\n
The runner needs a compiler.
\n
Possible sources:
\n
environment variables\nVix defaults\ndetected system compiler\nconfigured toolchain\ntarget triple
Common compiler candidates:
\n
c++\ng++\nclang++\ncl
The selected compiler becomes part of the script build identity.
\n
If the compiler changes, cached outputs may no longer be valid.
\n
Default standard
\n
Script mode should have a reasonable default C++ standard.
\n
For Vix, a good default is:
\n
c++20
The user should be able to override this if needed.
\n
Example idea:
\n
vix run main.cpp --std c++23
The exact CLI flag can evolve, but the model is clear:
\n
script mode has defaults\nadvanced users can override them
Output location
\n
The direct script runner should avoid polluting the current directory.
\n
Instead of producing:
\n
main\nmain.o\nmain.d
next to main.cpp, Vix can place outputs in an internal build or cache directory.
So even fallback mode can participate in cache and diagnostics.
\n
Common errors
\n
Source file not found
\n
Command:
\n
vix run main.cpp
but main.cpp does not exist.
\n
Vix should report:
\n
source file not found: main.cpp
Compile error
\n
The file exists, but the compiler fails.
\n
Vix should show the compiler diagnostic.
\n
Link error
\n
The file compiles, but linking fails.
\n
Vix should report the linker error and possibly suggest missing links or fallback.
\n
Runtime exit
\n
The program exits with non-zero status.
\n
Vix should report the program exit code.
\n
This is different from compile or link failure.
\n
Common design mistakes
\n
Treating script mode as project mode
\n
Wrong:
\n
vix run main.cpp requires vix.app
Correct:
\n
explicit source file uses script mode
Polluting the source directory
\n
Wrong:
\n
main.o appears next to main.cpp
Correct:
\n
Vix stores outputs in a managed directory
Ignoring runtime arguments
\n
Wrong:
\n
Vix consumes all flags
Correct:
\n
program arguments pass through after a clear boundary
Rebuilding every time
\n
Wrong:
\n
compile on every run even when nothing changed
Correct:
\n
reuse binary/object when inputs are unchanged
A practical first implementation
\n
A practical direct script runner should support:
\n
single .cpp file\ndefault C++ standard\nlocal includes\nVix include path\nmanaged output directory\ncompile diagnostics\nlink diagnostics\nruntime argument forwarding\ninteractive stdin\nexit code preservation\nsimple cache reuse\nfallback when direct mode is insufficient
This is enough to create a strong first experience.
That keeps the simple path simple while giving Vix room to become faster and more capable underneath.
\n';
+const vixDirectScriptRunner = {
+ html
+};
+export {
+ vixDirectScriptRunner as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-error-diagnostics-De4-bhrl.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-error-diagnostics-De4-bhrl.js
new file mode 100644
index 000000000..fbff8da3f
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-error-diagnostics-De4-bhrl.js
@@ -0,0 +1,664 @@
+const html = `
How Vix Turns C++ Errors Into Actionable Diagnostics
+
C++ is powerful because it gives developers direct control over memory, ownership, templates, concurrency, system calls, and runtime behavior.
+That power also comes with a cost.
+When something goes wrong, the error is often technically correct but difficult to act on:
+
terminate called after throwing an instance of 'std::runtime_error'
+Aborted (core dumped)
Or:
+
use of deleted function
Or:
+
no matching function for call to ...
Or:
+
AddressSanitizer: heap-use-after-free
The compiler, sanitizer, or runtime usually knows what failed.
+But it does not always present the failure in a way that helps the developer fix the code immediately.
+Vix.cpp treats this as a core developer experience problem.
+The goal is not to hide C++.
+The goal is to make C++ errors explain themselves.
+
The problem with raw C++ errors
+
C++ errors usually come from several different layers:
+
+
compiler
+
template instantiation
+
concept constraints
+
linker
+
runtime exception
+
std::terminate
+
sanitizers
+
operating system
+
filesystem
+
network
+
threading runtime
+
+
Each layer speaks a different language.
+A template error may expose implementation details from <type_traits> or <concepts>.
+A runtime crash may only say Aborted.
+
A sanitizer report may contain the correct stack trace, but the important user frame can be buried inside a large log.
+A filesystem error may be technically clear but not mapped to the line of user code that triggered it.
+Vix tries to normalize these failures into one shape:
+
+
error type
+
source location
+
code frame
+
human hint
+
raw log excerpt when needed
+
+
The output should answer four questions quickly:
+
+
What happened?
+
Where did it happen?
+
Why did it probably happen?
+
What should I check next?
+
+
The diagnostic pipeline
+
Vix error handling is built as a rule-based diagnostic pipeline.
+There are three major families:
+
+
build/compiler diagnostics
+
template and modern C++ diagnostics
+
runtime diagnostics
+
+
Each diagnostic rule is small, focused, and responsible for one family of errors.
+A rule generally does four things:
+
+
detect whether a log or compiler error belongs to its family
+
classify the specific subtype when possible
+
locate the best source line
+
print a code frame and actionable hint
+
+
This makes the system extensible.
+Instead of one large error parser trying to understand all of C++, Vix uses many precise rules.
+
Runtime diagnostics
+
Runtime errors are the hardest because they can come from undefined behavior, exceptions, operating system failures, sanitizers, or library-specific failures.
+Vix currently handles the following runtime families.
+
Process termination and aborts
+
+
AbortRule
+
ThreadJoinableRule
+
UncaughtExceptionRuntimeRule
+
+
These rules handle errors such as:
+
+
std::terminate called
+
terminate called after throwing an instance of ...
+
terminate called without an active exception
+
Aborted (core dumped)
+
SIGABRT
+
joinable std::thread destroyed
+
+
A raw abort is often too generic.
+
For example, this output is not enough:
+
terminate called after throwing an instance of 'std::runtime_error'
+Aborted (core dumped)
Vix extracts the actual exception reason when available:
+
what(): Failed to load environment configuration:
+failed to parse .env content at line 1: invalid .env line: key is invalid
Then it can point to the real file:
+
runtime error: environment configuration parse failed
+
+--> /home/softadastra/tmp/.env:1:1
+code:
+ 1 | production.websocket.host=127.0.0.1
+ ^
+ 2 | production.websocket.port=9090
+ 3 | production.websocket.path=/ws
+
+hint: fix the invalid environment file line; use KEY=value with a valid key name
+at: /home/softadastra/tmp/.env:1
That is the kind of diagnostic Vix is designed to produce.
+
Not just:
+
std::terminate called
But:
+
this exact config file has an invalid key on line 1
Memory safety diagnostics
+
C++ memory bugs are often catastrophic.
+Vix recognizes the most common memory safety families:
+
+
DoubleFreeRule
+
InvalidFreeRule
+
UseAfterFreeRule
+
MemoryLeakRule
+
BufferOverflowRule
+
StackOverflowRule
+
NullPointerRule
+
MisalignedAccessRule
+
+
These rules handle logs from libc, AddressSanitizer, UndefinedBehaviorSanitizer, and raw crashes.
+
Examples:
+
+
double free
+
invalid free
+
heap-use-after-free
+
stack-use-after-scope
+
heap-buffer-overflow
+
stack-buffer-overflow
+
global-buffer-overflow
+
stack overflow
+
null pointer dereference
+
misaligned memory access
+
+
The important design choice is that Vix avoids overly broad matches.
+For example, InvalidFreeRule does not trigger on invalid pointer alone, because that phrase can appear in unrelated contexts.
+
It requires stronger signals such as:
+
+
free(): invalid pointer
+
munmap_chunk(): invalid pointer
+
bad-free
+
AddressSanitizer + attempting free
+
AddressSanitizer + not malloc()-ed
+
+
This reduces false positives.
+
For memory bugs, Vix also keeps the raw sanitizer excerpt visible because the sanitizer often contains multiple important locations:
+
+
allocation site
+
free site
+
invalid use site
+
thread creation site
+
+
A friendly diagnostic should simplify the report without hiding evidence.
+
Container and iterator diagnostics
+
STL errors are common in real C++ code.
+
Vix handles:
+
+
EmptyContainerFrontBackRule
+
OutOfRangeAccessRule
+
InvalidIteratorDereferenceRule
+
IteratorInvalidationRule
+
+
These rules detect problems like:
+
+
front() on empty container
+
back() on empty container
+
pop_front() on empty container
+
pop_back() on empty container
+
top() on empty container
+
vector out-of-range access
+
string out-of-range access
+
map::at missing key
+
unordered_map::at missing key
+
invalid iterator dereference
+
end iterator dereference
+
singular iterator dereference
+
iterator invalidated by erase
+
iterator invalidated by reallocation
+
+
These are especially useful with debug STL modes and sanitizers.
+For example, raw STL diagnostics may say:
+
attempt to dereference a singular iterator
Vix turns that into:
+
runtime error: singular iterator dereference
+hint: initialize the iterator and refresh it after erase, insert, resize, reserve, or container reallocation
The goal is not to replace the STL diagnostic.
+The goal is to translate it into an immediate correction path.
+
Ownership and lifetime diagnostics
+
Modern C++ reduces many memory bugs through RAII, but lifetime mistakes still happen.
+Vix currently handles:
+
+
StringViewDanglingRuntimeRule
+
SpanLifetimeRule
+
DetachedThreadLifetimeRule
+
UseAfterFreeRule
+
NullPointerRule
+
+
These rules catch patterns such as:
+
+
dangling std::string_view
+
std::string_view outlived local string data
+
std::string_view points to freed memory
+
std::span outlived local storage
+
std::span invalidated by vector reallocation
+
detached thread captured expired stack data
+
detached thread used freed memory
+
+
These diagnostics are important because std::string_view and std::span do not own memory.
+They are safe only when the underlying storage outlives the view.
+This is valid:
+
std::string name = "vix";
+std::string_view view = name;
The compiler may not catch this.
+A sanitizer may catch it later.
+Vix turns that runtime failure into a lifetime-focused diagnostic.
+
Concurrency diagnostics
+
Concurrency bugs are among the hardest C++ problems to debug.
+Vix handles several families:
+
+
DataRaceRule
+
DeadlockRule
+
MutexMisuseRule
+
ConditionVariableMisuseRule
+
ThreadCreationFailureRule
+
ThreadJoinableRule
+
DetachedThreadLifetimeRule
+
FuturePromiseRule
+
+
These rules cover:
+
+
data race
+
lock-order inversion
+
deadlock
+
resource deadlock avoided
+
invalid mutex unlock
+
mutex used after destruction
+
condition variable wait without lock
+
condition variable destroyed while still in use
+
thread resource limit reached
+
pthread_create failed
+
joinable std::thread destroyed
+
broken promise
+
promise already satisfied
+
future already retrieved
+
future has no associated state
+
+
Concurrency diagnostics must be careful.
+
For example, a ThreadSanitizer data race report usually has at least two important locations:
+
+
current read/write
+
previous conflicting read/write
+
thread creation site
+
+
Vix does not hide that log.
+
Instead, it prints a short human explanation and keeps the runtime log excerpt visible:
+
runtime error: data race between read and write
+
+hint: protect every read and write of the shared value with the same mutex, or make the value atomic
+hint: do not ignore the runtime log: data races usually require comparing both conflicting stack traces
This is important because data races are not single-line bugs.
+They are relationship bugs between multiple execution paths.
+
Arithmetic and undefined behavior diagnostics
+
Vix also handles common undefined behavior families:
+
+
DivisionByZeroRule
+
IntegerOverflowRule
+
UninitializedMemoryRule
+
MisalignedAccessRule
+
InvalidCastRule
+
PureVirtualCallRule
+
+
These detect errors such as:
+
+
division by zero
+
SIGFPE
+
signed integer overflow
+
invalid shift
+
use of uninitialized value
+
misaligned address
+
invalid vptr
+
bad dynamic cast
+
bad_any_cast
+
bad_variant_access
+
pure virtual function call
+
+
These are often reported by UBSan, MSan, or the C++ runtime.
+A raw UBSan message may be correct, but Vix makes the output more directly actionable:
+
runtime error: signed integer overflow
+hint: use wider integer types or check bounds before arithmetic
Or:
+
runtime error: pure virtual function call
+hint: avoid calling virtual functions from constructors/destructors or after object destruction
These diagnostics matter because many undefined behavior bugs do not fail immediately in release mode.
+They may silently corrupt program behavior.
+
Filesystem, network, and OS diagnostics
+
Not every runtime error is memory-related.
+Vix also handles operational failures:
+
+
FilesystemRuntimeRule
+
PermissionDeniedRule
+
AddressAlreadyInUseRule
+
BrokenPipeRule
+
TimeoutRuntimeRule
+
JsonParseRuntimeRule
+
ConfigParseRuntimeRule
+
+
These cover:
+
+
filesystem error
+
file not found
+
path is not a directory
+
path already exists
+
permission denied
+
address already in use
+
port already in use
+
broken pipe
+
connection reset by peer
+
operation timed out
+
JSON parse failed
+
environment configuration parse failed
+
+
This matters because C++ applications increasingly behave like systems software:
+
+
servers
+
CLIs
+
build tools
+
package managers
+
database clients
+
network runtimes
+
edge applications
+
offline-first systems
+
+
A good C++ runtime should explain not only pointer errors, but also system-level failures.
+
Example:
+
runtime error: address already in use
+hint: port 8080 is already in use; stop the other process or change the port
Or:
+
runtime error: broken pipe
+hint: the peer closed the connection before the write completed; handle disconnects and retry only when safe
This is not language-level C++ only.
+It is production C++.
+
Template and modern C++ diagnostics
+
Runtime diagnostics are only one side.
+C++ also has extremely complex compile-time errors, especially around templates, concepts, overload resolution, coroutines, ownership types, and modern library features.
+Vix currently handles these template and modern C++ families:
+
+
DependentTypenameRule
+
NoTypeNamedRule
+
TemplateArgumentMismatchRule
+
InvalidTemplateTemplateArgumentRule
+
CtadFailureRule
+
RequiresExpressionFailureRule
+
ConceptConstraintFailureRule
+
NoMatchingOverloadWithConstraintsRule
+
SubstitutionFailureRule
+
StaticAssertFailureRule
+
ConstexprEvaluationFailureRule
+
MoveOnlyCopyRule
+
DeletedFunctionRule
+
PrivateConstructorRule
+
InaccessibleMemberRule
+
IncompleteTypeRule
+
NoViableConversionRule
+
ConstQualifierRule
+
InvalidReferenceBindingRule
+
InvalidInitializerListRule
+
NarrowingConversionRule
+
MissingBeginEndRule
+
OperatorNotFoundRule
+
AllocatorValueTypeMismatchRule
+
TupleVariantAccessRule
+
InvalidUseOfVoidRule
+
LambdaCaptureLifetimeRule
+
NonVirtualDestructorDeleteRule
+
ObjectSlicingRule
+
BadOverrideRule
+
InvalidDowncastRule
+
CoroutineReturnTypeRule
+
MissingCoReturnRule
+
InvalidAwaitableRule
+
NoMemberAwaitReadyRule
+
NoMemberAwaitSuspendRule
+
NoMemberAwaitResumeRule
+
InvalidPromiseTypeRule
+
+
This is a large part of the C++ developer experience problem.
+A beginner may struggle with:
+
+
missing semicolon
+
header not found
+
cout not declared
+
+
But an experienced C++ developer often loses time on:
+
+
substitution failure
+
failed constraint
+
requires-expression failure
+
invalid awaitable
+
bad override
+
deleted copy constructor
+
CTAD failure
+
static_assert failure
+
consteval/constexpr failure
+
invalid template template argument
+
+
Vix aims to make those failures readable.
+
Concepts and constraints
+
Modern C++ uses concepts to encode requirements.
+When constraints fail, the compiler often emits a long instantiation trace.
+
Vix recognizes:
+
+
ConceptConstraintFailureRule
+
RequiresExpressionFailureRule
+
NoMatchingOverloadWithConstraintsRule
+
SubstitutionFailureRule
+
+
These diagnostics focus on the actual missing requirement.
+Instead of leaving the user with a long template backtrace, Vix tries to produce a message closer to:
+
error: concept constraint failed
+hint: check which required expression, type, or operation is not satisfied
This is especially important for libraries that use heavily constrained APIs.
+
Coroutine diagnostics
+
C++ coroutines have very specific rules.
+A coroutine type must expose the right promise type and awaitable operations.
+Vix recognizes:
+
+
CoroutineReturnTypeRule
+
MissingCoReturnRule
+
InvalidAwaitableRule
+
InvalidPromiseTypeRule
+
NoMemberAwaitReadyRule
+
NoMemberAwaitSuspendRule
+
NoMemberAwaitResumeRule
+
+
These cover errors like:
+
+
missing co_return
+
invalid coroutine return type
+
promise_type missing
+
await_ready missing
+
await_suspend missing
+
await_resume missing
+
+
The goal is to map coroutine compiler errors back to the coroutine mental model:
+
+
promise_type
+
co_await protocol
+
co_return
+
await_ready
+
await_suspend
+
await_resume
+
+
Ownership diagnostics at compile time
+
Some ownership bugs are runtime bugs.
+Others are visible at compile time.
+Vix handles compile-time ownership patterns such as:
+
+
MoveOnlyCopyRule
+
DeletedFunctionRule
+
NonVirtualDestructorDeleteRule
+
ObjectSlicingRule
+
InvalidDowncastRule
+
LambdaCaptureLifetimeRule
+
+
These help with errors like:
+
+
copying std::unique_ptr
+
copying std::thread
+
copying a move-only type
+
deleting derived object through non-virtual base destructor
+
object slicing
+
invalid downcast
+
lambda captures unsafe reference
+
+
For example, a raw compiler error might say:
+
use of deleted function 'std::unique_ptr<T>::unique_ptr(const std::unique_ptr<T>&)'
Vix can turn that into:
+
error: copy of move-only type
+hint: use std::move, pass by reference, or delete copying intentionally
This is better because it explains the C++ rule, not only the failed symbol.
+
Why ordering matters
+
The diagnostic pipeline is ordered.
+This matters because many errors overlap.
+For example:
+
std::out_of_range
could be handled by a generic uncaught exception rule.
+But a better rule exists:
+
OutOfRangeAccessRule
So the specialized rule must run first.
+Another example:
+
failed to parse .env content at line 1
could be seen as an uncaught std::runtime_error.
+But the better rule is:
+
ConfigParseRuntimeRule
So it must run before generic exception handling.
+The same applies to memory errors:
+
AddressSanitizer: heap-use-after-free
should be handled by:
+
UseAfterFreeRule
not by a generic segfault or abort rule.
+This is why Vix keeps broad fallback rules at the end:
+
+
SegfaultRule
+
AbortRule
+
+
They are still useful, but only when no better rule can explain the failure.
+
Avoiding false positives
+
Good diagnostics are not only about matching more errors.
+They are also about avoiding wrong explanations.
+Vix rules are intentionally conservative.
+
Examples:
+
InvalidFreeRule does not match invalid pointer alone, because that phrase is too generic.
+BrokenPipeRule does not match write failed alone unless socket, stream, or connection context is present.
+JsonParseRuntimeRule does not match unexpected token unless JSON context is present.
+FilesystemRuntimeRule steps aside when permission-specific signals are present, so PermissionDeniedRule can produce the better message.
+This is important.
+
A wrong friendly diagnostic is worse than a raw compiler error.
+
The role of raw logs
+
Vix does not try to hide the original compiler, sanitizer, or runtime log.
+Instead, it gives a better first explanation and keeps the relevant log excerpt visible.
+This is especially important for:
+
+
data races
+
deadlocks
+
use-after-free
+
double free
+
buffer overflows
+
template substitution failures
+
concept failures
+
uncaught exceptions
+
+
Many advanced C++ failures cannot be fully explained from a single line.
+The diagnostic should guide the developer without removing the original evidence.
+
What this means for Vix
+
Vix is not only a build tool.
+Vix is becoming a C++ runtime and developer system that understands the failure modes of real C++ programs.
+That includes:
+
+
compilation
+
templates
+
concepts
+
coroutines
+
ownership
+
memory safety
+
threading
+
filesystem
+
networking
+
configuration
+
runtime crashes
+
sanitizers
+
+
The goal is simple:
+C++ should remain powerful.
+The error experience should become humane.
+
A developer should not need to decode a 200-line template trace just to understand that a type is missing begin().
+
A developer should not only see Aborted (core dumped) when the real issue is line 1 of .env.
+A developer should not lose time guessing whether a crash is a null pointer, use-after-free, invalid iterator, or joinable thread destruction.
+Vix gives the error a name, a location, and a next step.
+
Current diagnostic families managed by Vix
+
Runtime families
+
+
AbortRule
+
ThreadJoinableRule
+
UncaughtExceptionRuntimeRule
+
DataRaceRule
+
DeadlockRule
+
ConditionVariableMisuseRule
+
MutexMisuseRule
+
FuturePromiseRule
+
ThreadCreationFailureRule
+
DetachedThreadLifetimeRule
+
DoubleFreeRule
+
InvalidFreeRule
+
UseAfterFreeRule
+
MemoryLeakRule
+
BufferOverflowRule
+
StackOverflowRule
+
NullPointerRule
+
DivisionByZeroRule
+
IntegerOverflowRule
+
UninitializedMemoryRule
+
MisalignedAccessRule
+
InvalidCastRule
+
PureVirtualCallRule
+
EmptyContainerFrontBackRule
+
OutOfRangeAccessRule
+
InvalidIteratorDereferenceRule
+
IteratorInvalidationRule
+
StringViewDanglingRuntimeRule
+
SpanLifetimeRule
+
FilesystemRuntimeRule
+
PermissionDeniedRule
+
AddressAlreadyInUseRule
+
BrokenPipeRule
+
TimeoutRuntimeRule
+
JsonParseRuntimeRule
+
ConfigParseRuntimeRule
+
SegfaultRule
+
+
Template and modern C++ families
+
+
DependentTypenameRule
+
NoTypeNamedRule
+
TemplateArgumentMismatchRule
+
InvalidTemplateTemplateArgumentRule
+
CtadFailureRule
+
RequiresExpressionFailureRule
+
ConceptConstraintFailureRule
+
NoMatchingOverloadWithConstraintsRule
+
SubstitutionFailureRule
+
StaticAssertFailureRule
+
ConstexprEvaluationFailureRule
+
MoveOnlyCopyRule
+
DeletedFunctionRule
+
PrivateConstructorRule
+
InaccessibleMemberRule
+
IncompleteTypeRule
+
NoViableConversionRule
+
ConstQualifierRule
+
InvalidReferenceBindingRule
+
InvalidInitializerListRule
+
NarrowingConversionRule
+
MissingBeginEndRule
+
OperatorNotFoundRule
+
AllocatorValueTypeMismatchRule
+
TupleVariantAccessRule
+
InvalidUseOfVoidRule
+
LambdaCaptureLifetimeRule
+
NonVirtualDestructorDeleteRule
+
ObjectSlicingRule
+
BadOverrideRule
+
InvalidDowncastRule
+
CoroutineReturnTypeRule
+
MissingCoReturnRule
+
InvalidAwaitableRule
+
NoMemberAwaitReadyRule
+
NoMemberAwaitSuspendRule
+
NoMemberAwaitResumeRule
+
InvalidPromiseTypeRule
+
+
Beginner and common compile-time families
+
+
CoutNotDeclaredRule
+
HeaderNotFoundRule
+
MissingSemicolonRule
+
VectorOstreamRule
+
ProcessNullptrAmbiguityRule
+
UniquePtrCopyRule
+
SharedPtrRawPtrMisuseRule
+
DeleteMismatchRule
+
UseAfterMoveRule
+
DanglingStringViewRule
+
ReturnLocalRefRule
+
UseOfUninitializedRule
+
+
Conclusion
+
C++ does not need to become less powerful to become more accessible.
+The language can stay explicit, native, and close to the system.
+But the tooling around it should be better.
+Vix.cpp is building that layer.
+A layer that understands C++ errors.
+A layer that turns raw compiler output, runtime crashes, and sanitizer logs into diagnostics developers can act on immediately.
+That is the direction:
+
+
less guessing
+
less hidden context
+
better source locations
+
better hints
+
better C++ developer experience
+
+
C++ errors should not only be correct.
+They should be useful.
+`;
+const vixErrorDiagnostics = {
+ html
+};
+export {
+ vixErrorDiagnostics as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-game-module-foundation-BiGuToG6.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-game-module-foundation-BiGuToG6.js
new file mode 100644
index 000000000..3c95c3520
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-game-module-foundation-BiGuToG6.js
@@ -0,0 +1,8 @@
+const html = '
Building the Vix Game Foundation
\n
Vix.cpp is not only about compiling and running C++ faster.\nIt is also about giving developers a cleaner runtime model for building real applications.\nvix/game is one step in that direction.
\n
It introduces a game application foundation for Vix.cpp: a small, modular runtime layer for building games, simulations, prototypes, interactive tools, and custom engines.\nThe goal is not to replace Unity, Unreal, Godot, SDL, GLFW, Vulkan, OpenGL, Box2D, Lua, or any existing game technology.
\n
The goal is simpler:
\n
\n
Give C++ developers a serious foundation for real-time applications without locking them into a complete engine.
\n
\n
Why vix/game exists
\n
Most C++ game projects start by rebuilding the same foundation:
\n
\n
application loop
\n
frame timing
\n
scene management
\n
events
\n
asset loading
\n
background jobs
\n
input state
\n
window abstraction
\n
renderer abstraction
\n
runtime orchestration
\n
editor, scripting, audio, and physics layers
\n
\n
These systems are usually scattered across the application, tied to a specific backend, or mixed directly into game code.
\n
vix/game exists to avoid that.
\n
It provides a clean structure while keeping the developer in control.
\n
The design principle
\n
The module follows one clear principle:
\n
\n
Build the foundation, not the prison.\nA game engine gives you everything, but often forces you into its architecture.\nvix/game takes a different path.\nIt gives you the runtime pieces needed to build your own architecture:
\n
\n
\n
App
\n
GameLoop
\n
Frame
\n
EventBus
\n
SceneManager
\n
Registry
\n
AssetManager
\n
AsyncAssetLoader
\n
JobSystem
\n
InputSystem
\n
Window
\n
Renderer
\n
Renderer2D
\n
GameRuntime
\n
EditorRuntime
\n
ScriptRuntime
\n
AudioRuntime
\n
PhysicsRuntime
\n
GamePackage
\n
\n
Each part stays explicit, readable, and backend-independent.
\n
A backend-independent foundation
\n
vix/game does not force a specific backend.
\n
It does not require SDL.\nIt does not require GLFW.\nIt does not require OpenGL.\nIt does not require Vulkan.\nIt does not require Box2D.\nIt does not require Lua.\nThat is intentional.
\n
The first job of the module is to define a stable runtime surface. Real backends can be integrated later without changing the high-level architecture.
\n
This makes the module useful for:
\n
\n
small games
\n
game prototypes
\n
simulations
\n
real-time visualization tools
\n
custom engines
\n
editor tools
\n
educational engine architecture
\n
future Vix-powered game workflows
\n
\n
Core architecture
\n
The current architecture is organized around runtime layers.
App does not become a giant engine object.\nIt remains the root of the application lifecycle, while dedicated runtime objects coordinate the larger systems.
\n
Basic example
\n
A minimal game can be written with a scene and a runtime.
\n
#include <vix/game/all.hpp>\n#include <vix/print.hpp>\n\nclass MainScene final : public vix::game::Scene\n{\npublic:\n vix::game::GameBoolResult on_load() override\n {\n vix::print("Main scene loaded");\n return vix::game::Scene::on_load();\n }\n\n void on_update(const vix::game::Frame& frame) override\n {\n vix::print("frame:", frame.index);\n\n if (frame.index >= 5)\n {\n app().stop();\n }\n }\n};\n\nint main()\n{\n vix::game::App app;\n app.set_title("My Game");\n\n vix::game::GameRuntime runtime(app);\n\n auto runtime_init = runtime.init();\n if (!runtime_init)\n {\n vix::print("runtime init failed:", runtime_init.error().message());\n return 1;\n }\n\n auto scene = app.scenes().create<MainScene>("main");\n if (!scene)\n {\n vix::print("scene creation failed:", scene.error().message());\n return 1;\n }\n\n auto active = app.scenes().set_active("main");\n if (!active)\n {\n vix::print("scene activation failed:", active.error().message());\n return 1;\n }\n\n auto result = app.run();\n if (!result)\n {\n vix::print("game failed:", result.error().message());\n return 1;\n }\n\n return 0;\n}
This example shows the direction of the module:
\n
\n
explicit application root
\n
explicit runtime initialization
\n
explicit scene creation
\n
explicit error handling
\n
no hidden engine magic
\n
\n
Game projects from the CLI
\n
vix/game is also integrated with the Vix CLI.
\n
A new game project can be generated with:
\n
vix new mario --game\ncd mario\nvix build\nvix run
This matters because the goal is not only to provide C++ APIs.\nThe goal is to make the complete development workflow smoother.\nA developer should be able to create, build, and run a C++ game project without manually wiring everything from scratch.
This keeps the project simple while still allowing Vix to use its native build pipeline internally.\nThe developer gets a clean manifest.\nVix handles the build structure.
\n
What is completed
\n
The module has grown through three foundation stages.
\n
V1
\n
V1 focused on the core runtime base:
\n
\n
App
\n
game loop
\n
TimeStep
\n
Frame
\n
EventBus
\n
SceneManager
\n
simple Registry
\n
AssetManager
\n
JobSystem
\n
examples
\n
tests
\n
\n
V2
\n
V2 added more real game architecture concepts:
\n
\n
input module
\n
window abstraction
\n
renderer abstraction
\n
2D rendering foundation
\n
asset cache
\n
async asset loading
\n
scene serialization
\n
stronger ECS iteration APIs
\n
\n
V3
\n
V3 introduced higher-level runtime separation:
\n
\n
GameContext
\n
GameRuntime
\n
EditorContext
\n
EditorRuntime
\n
SceneRuntime
\n
ScriptRuntime
\n
AudioRuntime
\n
PhysicsRuntime
\n
GamePackage
\n
vix new --game template
\n
runtime smoke example
\n
\n
This gives the module a clearer long-term direction.
\n
What comes next
\n
The next step is real backend integration.
\n
Planned areas include:
\n
\n
real window backend integration
\n
real renderer backend integration
\n
sprite rendering backend
\n
asset pipeline improvements
\n
editor tool APIs
\n
scene inspection APIs
\n
runtime diagnostics
\n
scripting backend integration
\n
audio backend integration
\n
physics backend integration
\n
game packaging command
\n
game export workflow
\n
\n
The important part is that these future pieces can now be built on top of a stable foundation.
\n
Why this matters for Vix.cpp
\n
Vix.cpp is becoming more than a command-line tool.\nIt is becoming a runtime foundation for building real C++ software.\nvix/game proves that the same ideas behind Vix can apply to interactive applications:
\n
\n
explicit APIs
\n
fast workflows
\n
modular architecture
\n
clean errors
\n
backend independence
\n
progressive complexity
\n
real C++ control
\n
\n
C++ gives developers power.\nVix tries to make that power easier to use.\nvix/game brings that philosophy to games and real-time software.
\n
Final note
\n
vix/game is not trying to be a complete game engine.\nIt is trying to be the layer before the engine.
\n
A foundation.\nA place where developers can start small, understand the runtime, and grow their own architecture without losing control.
\n';
+const vixGameModuleFoundation = {
+ html
+};
+export {
+ vixGameModuleFoundation as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-game-runtime-export-workflow-wLIk7cIo.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-game-runtime-export-workflow-wLIk7cIo.js
new file mode 100644
index 000000000..f513bf706
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-game-runtime-export-workflow-wLIk7cIo.js
@@ -0,0 +1,8 @@
+const html = '
From Runtime to Export: vix/game V4 and V5
\n
vix/game started as a clean game application foundation for Vix.cpp.\nThe first versions focused on the base runtime pieces:
\n
\n
application lifecycle
\n
game loop
\n
frame timing
\n
scenes
\n
events
\n
assets
\n
jobs
\n
input
\n
window abstraction
\n
renderer abstraction
\n
runtime layers
\n
\n
That foundation matters because C++ game projects often become complex before the first real feature is even built.
\n
But a foundation is only useful if it can grow.\nV4 and V5 move vix/game from a simple runtime base toward something more complete:
\n
\n
V4 connects the runtime to real window and rendering backends.
Build the foundation, not the prison.\nvix/game is not trying to become a locked game engine.\nIt gives developers the runtime pieces needed to build games, simulations, tools, prototypes, and custom engines on top of Vix.cpp.
\n
\n
Why V4 matters
\n
Before V4, the module already had a strong internal structure.
\n
It had:
\n
\n
App
\n
GameLoop
\n
SceneManager
\n
AssetManager
\n
InputSystem
\n
Window
\n
Renderer
\n
Renderer2D
\n
GameContext
\n
GameRuntime
\n
EditorRuntime
\n
\n
But most of the architecture was still backend-independent.
\n
That was intentional.\nThe first job was to define the runtime surface before attaching it to real platform backends.\nV4 is where the module starts crossing that line.\nIt keeps the clean abstractions, but adds the first real backend path.
\n
Runtime coordination
\n
V4 makes GameRuntime the main runtime coordinator.\nInstead of pushing every responsibility into App, runtime orchestration lives in dedicated objects.\nThis keeps the architecture clean.
App remains the lifecycle root.\nGameContext gives systems access to shared runtime services.\nGameRuntime coordinates the higher-level execution flow.\nThis separation is important because the module will later need editor tools, scripting, audio, physics, packaging, and diagnostics without turning App into a giant engine object.
\n
Backend installation through GameContext
\n
V4 improves GameContext so runtime backends can be installed cleanly.\nThat means a game can run with:
\n
\n
a null window
\n
a null renderer
\n
an SDL window
\n
an SDL renderer
\n
future custom backends
\n
\n
This matters for testing and CI.\nA game module should not require a graphical backend just to validate core logic.\nHeadless execution remains possible, while real rendering becomes available when a backend is installed.
This gives Vix a runtime model that can work both for local development and automated builds.
\n
SDL window backend
\n
V4 adds the first SDL window backend path.\nThe module can now create an SDL-backed window while keeping the public API backend-independent.\nThe high-level code should not be forced to know whether the window comes from SDL, GLFW, a null backend, or a future platform layer.\nThat is the point of the abstraction.
\n
Game code\n -> Window interface\n -> SDLWindow backend
The result is simple:
\n
\n
game code targets vix/game
\n
backend code handles SDL details
\n
tests can still use null backends
\n
future backends can be added without changing the mental model
\n
\n
SDL input mapping
\n
Windowing alone is not enough.\nA real runtime also needs input.\nV4 connects SDL input events to the backend-independent InputSystem.\nThe input layer supports:
\n
\n
key state
\n
pointer button state
\n
pointer position
\n
pointer delta
\n
wheel delta
\n
action bindings
\n
pressed, down, and released queries
\n
\n
Game code can bind actions without being tied directly to SDL events.
This keeps the game-facing API stable.\nSDL becomes an implementation detail.
\n
SDL renderer backend
\n
V4 also introduces an SDL renderer backend.\nThis is a major step because the module moves from abstract rendering concepts to visible output.\nThe rendering path becomes:
Renderer2D stays as the high-level 2D rendering API.\nSDLRenderer handles the backend-specific rendering work.\nThis gives Vix a first real path toward 2D games, tools, and simulations without locking the architecture to SDL forever.
\n
Sprite rendering
\n
V4 adds sprite rendering through the SDL renderer path.
This is important because it connects multiple systems together:
\n
\n
assets
\n
renderer abstraction
\n
texture upload
\n
2D command collection
\n
backend drawing
\n
\n
That means vix/game is no longer only a runtime skeleton.\nIt can now demonstrate a real rendering pipeline.
\n
Runtime diagnostics and inspection
\n
V4 also adds runtime diagnostics and inspection APIs.\nThis prepares the module for more serious tooling.\nA game runtime should not be a black box.\nDevelopers need to inspect:
\n
\n
runtime state
\n
scene state
\n
editor state
\n
backend state
\n
frame behavior
\n
active systems
\n
\n
This is especially important for future editor tools.\nThe editor layer cannot be added cleanly if the runtime cannot expose useful information.\nV4 starts preparing that surface.
\n
Why V5 matters
\n
V4 makes the runtime more real.\nV5 makes the workflow more complete.\nA game project is not only code that runs locally.
\n
It also needs:
\n
\n
project metadata
\n
asset metadata
\n
generated templates
\n
export output
\n
inspectable manifests
\n
CLI commands
\n
predictable project layout
\n
\n
V5 adds that layer.\nThe main feature is:
\n
vix game export
This command turns a game project into an exported directory with copied assets, package metadata, and an export manifest.
\n
Game package metadata
\n
V5 builds on GamePackage.
\n
A game project can describe itself with metadata such as:
\n
\n
name
\n
version
\n
author
\n
entry scene
\n
asset root
\n
output directory
\n
scene list
\n
asset list
\n
\n
This metadata is the base for future workflows:
\n
\n
project creation
\n
game export
\n
packaging
\n
editor loading
\n
release preparation
\n
distribution metadata
\n
\n
The important part is that this metadata is explicit.\nVix should not guess everything silently.\nThe project should be inspectable.
\n
vix new --game template
\n
V5 also improves the generated game template.\nA new game project can be created with:
\n
vix new mario --game\ncd mario\nvix build\nvix dev\nvix game export
That matters because Vix is not only a library collection.\nIt is also a workflow.\nThe developer should be able to create a game project, build it, run it, and export it without manually wiring every file.
This keeps the project readable.\nThe developer sees a small manifest.\nVix handles the native build structure internally.\nThat is the direction of Vix:
\n
\n
Keep the workflow simple without removing the power of C++.
\n
\n
Game export workflow
\n
V5 adds a complete export workflow.\nA game can now be exported with:
\n
vix game export
The command reads game.package.json, scans the asset root, copies exportable files, and generates an export manifest.
\n
Example output:
\n
✔ Game exported.\n • Output : ./dist/mario\n • Name : mario\n • Version : 0.1.0\n • Asset root: assets\n • Copied files: 4\n • Copied directories: 1
This is the first step toward real packaging.\nIt is not yet a full release builder.\nIt does not try to solve everything immediately.\nBut it gives the project a stable export shape.
\n
export.json
\n
The generated export.json makes the export inspectable.\nIt can contain:
\n
\n
game name
\n
version
\n
asset root
\n
output path
\n
copied file count
\n
copied directory count
\n
build date
\n
exported asset list
\n
\n
This matters because export should not be a hidden copy operation.\nA developer should be able to inspect what was exported and why.\nThat also prepares future features:
\n
\n
asset hashing
\n
asset bundling
\n
release profiles
\n
editor export tools
\n
distribution metadata
\n
reproducible packaging
\n
\n
Asset export pipeline
\n
V5 adds a small asset export pipeline.\nThe pipeline scans the configured asset root and classifies exported assets.\nSupported asset categories include:
The pipeline also ignores temporary and cache files.
\n
Examples:
\n
\n
.gitkeep
\n
.DS_Store
\n
Thumbs.db
\n
cache/
\n
tmp/
\n
temp/
\n
build/
\n
dist/
\n
*.tmp
\n
*.cache
\n
*.log
\n
\n
This keeps the export clean.\nThe first version does not transform, compress, hash, or bundle assets yet.\nIt only discovers, classifies, copies, and records them.\nThat is enough for a clear V5 export foundation.
\n
vix dev behavior for games
\n
V5 also fixes vix dev behavior for short-lived game applications.\nThis is important because the default generated game template may run for only a few frames and then stop.\nThat is normal for a smoke test or generated starter project.\nA development command should handle that cleanly instead of treating every short-lived run as a broken workflow.
\n
This improves the first experience after:
\n
vix new mario --game\ncd mario\nvix dev
The generated application can initialize, run, print frames, and shut down cleanly.\nExpected output:
\n
Main scene loaded\ngame app initialized title=mario\nframe: 0\nframe: 1\nframe: 2\nframe: 3\nframe: 4\nframe: 5\ngame app shutdown title=mario
What V4 and V5 prove
\n
Together, V4 and V5 prove that vix/game is moving in the right direction.\nV4 proves the runtime can connect to real backends:
\n
\n
SDL window
\n
SDL input
\n
SDL renderer
\n
texture upload
\n
sprite rendering
\n
runtime diagnostics
\n
scene inspection
\n
\n
V5 proves the workflow can become complete:
\n
\n
game project template
\n
package metadata
\n
asset scanning
\n
export manifest
\n
vix game export
\n
generated export directory
\n
cleaner vix dev behavior
\n
\n
This is the bridge between a runtime foundation and a real game development workflow.
\n
What comes next
\n
V6 should build on this foundation.
\n
The next logical steps are:
\n
\n
scripting backend integration
\n
audio backend integration
\n
physics backend integration
\n
editor tool APIs
\n
asset hashing
\n
asset bundling
\n
export profiles
\n
release packaging
\n
richer project templates
\n
\n
The important thing is that these features now have a place to live.\nThey do not need to be forced into App.\nThey can build on the existing runtime layers, package metadata, and export pipeline.
\n
Why this matters for Vix.cpp
\n
Vix.cpp is not only about making C++ builds easier.\nIt is about making C++ application development feel more direct.\nvix/game shows that this philosophy can apply to games and real-time software:
\n
\n
explicit APIs
\n
backend independence
\n
simple project creation
\n
clean runtime architecture
\n
native C++ control
\n
generated templates
\n
exportable projects
\n
inspectable metadata
\n
\n
The goal is not to compete directly with Unity, Unreal, or Godot.\nThe goal is different.\nvix/game is the layer before the engine.\nIt gives C++ developers a foundation they can understand, extend, and control.
\n
Final note
\n
V4 made the runtime visible.\nV5 made the project exportable.\nThat is an important step for Vix.cpp.\nA C++ game project should not begin with build system pain, backend confusion, and scattered runtime code.
\n
It should begin with a clean foundation:
\n
vix new mario --game\ncd mario\nvix dev\nvix game export
That is the direction of vix/game.
\n';
+const vixGameRuntimeExportWorkflow = {
+ html
+};
+export {
+ vixGameRuntimeExportWorkflow as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-object-cache-incremental-builds-Cs72iJr-.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-object-cache-incremental-builds-Cs72iJr-.js
new file mode 100644
index 000000000..0db71fe23
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-object-cache-incremental-builds-Cs72iJr-.js
@@ -0,0 +1,8 @@
+const html = '
vix Object Cache and Incremental Builds
\n
C++ builds become slow when the build system repeats work that did not need to happen.
\n
The compiler may be fast enough for one file.
\n
The problem appears when the build system recompiles too much:
main.o stays valid\napp.o becomes dirty\nmyapp must relink
A good build system should rebuild only:
\n
app.o\nmyapp
not:
\n
main.o
Why object caching matters
\n
Incremental builds already avoid some work.
\n
But an object cache goes further.
\n
It can reuse compiled objects even when the build directory was cleaned, recreated, or moved, as long as the compile inputs are identical.
\n
Example:
\n
first build:\n compile src/main.cpp -> main.o\n store main.o in object cache\n\nlater build:\n same source\n same headers\n same flags\n same compiler\n restore main.o from cache
This turns repeated compilation into a file restore.
\n
Object cache vs normal incremental build
\n
A normal incremental build asks:
\n
Is the existing object file in the build directory still valid?
An object cache asks:
\n
Have I ever built this exact object before?
That distinction matters.
\n
If the build directory is removed:
\n
rm -rf build-ninja
a normal incremental build loses its objects.
\n
But an object cache may still restore them.
\n
Correctness comes first
\n
An object cache must be conservative.
\n
A wrong cache hit is worse than a slow build.
\n
If Vix is unsure whether an object file is valid, it should recompile.
\n
The rule should be:
\n
reuse only when the full compile identity matches
The cache key must include every input that can affect the object file.
\n
Compile identity
\n
The compile identity is the full set of information that makes one object file valid.
Even if the source file is unchanged, the output object may differ.
\n
So Vix needs a command hash.
\n
Compiler identity
\n
The compiler itself matters.
\n
These are not necessarily equivalent:
\n
g++ 13\ng++ 14\nclang++ 18
A cache entry produced by one compiler version may not be safe for another compiler version.
\n
The object cache key should include compiler identity.
\n
At minimum:
\n
compiler path\ncompiler version\ntarget triple
Build type
\n
Debug and release builds are different.
\n
A debug object may be compiled with:
\n
-g\n-O0
A release object may be compiled with:
\n
-O3\n-DNDEBUG
Those outputs are not interchangeable.
\n
The build type or full compiler command must be part of the cache key.
\n
Include directories
\n
Include directories affect which headers are found.
\n
This command:
\n
g++ -Iinclude -c src/app.cpp
can produce a different result from:
\n
g++ -Iother_include -c src/app.cpp
Even if the source file text is the same, the compiler may read different headers.
\n
Include paths must be part of the compile identity.
\n
Defines
\n
Preprocessor definitions affect compilation.
\n
Example:
\n
defines = [\n MYAPP_ENABLE_LOGGING=1,\n]
This can change compiled code.
\n
So definitions must be included in the cache key.
\n
C++ standard
\n
The selected standard changes how code is parsed and compiled.
\n
standard = c++20
is not equivalent to:
\n
standard = c++23
The C++ standard must be part of the object identity.
\n
Target triple
\n
Cross-compilation changes the output.
\n
A cached object for:
\n
x86_64-linux-gnu
cannot be reused for:
\n
aarch64-linux-gnu
The target triple must be part of the cache key.
\n
Object cache flow
\n
A compile task can follow this flow:
\n
1. compute compile identity\n2. look for object in cache\n3. if cache hit:\n restore object file\n restore dependency file if available\n4. if cache miss:\n run compiler\n store object file in cache\n store dependency file in cache
This gives a simple and safe model.
\n
Cache hit
\n
A cache hit means:
\n
Vix found a previously compiled object with the same compile identity.
Vix should eventually expose this in verbose output.
\n
Example:
\n
objects: 18 selected, 16 cache hits, 2 compiled
This helps engineers trust the cache.
\n
Explaining rebuilds
\n
Fast builds are useful.
\n
Explainable builds are better.
\n
Vix should eventually answer:
\n
Why did this file rebuild?
Example explanations:
\n
src/app.cpp rebuilt because source changed\nsrc/main.cpp rebuilt because include/config.hpp changed\nsrc/server.cpp rebuilt because compile options changed
If Vix cannot prove that a cached object is valid, it should compile.
\n
A slow correct build is acceptable.
\n
A fast wrong build is not.
\n
Conclusion
\n
Object caching is one of the main ways vix build can become significantly faster.
\n
It works by reusing compiled object files when the full compile identity matches.
\n
That identity includes more than the source file.
\n
It includes headers, compiler, flags, defines, include paths, standard, target triple, and build configuration.
\n
Combined with the BuildGraph, Scheduler, and ArtifactCache, the object cache gives Vix a path toward much faster incremental builds.
\n
The long-term direction is:
\n
vix.app\n -> BuildGraph\n -> ObjectCache\n -> Scheduler\n -> Link
That is where Vix can make repeated C++ builds feel dramatically faster without pretending that C++ compilation itself is free.
\n';
+const vixObjectCacheIncrementalBuilds = {
+ html
+};
+export {
+ vixObjectCacheIncrementalBuilds as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-replay-D153V5vm.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-replay-D153V5vm.js
new file mode 100644
index 000000000..3f32fa2d0
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-replay-D153V5vm.js
@@ -0,0 +1,8 @@
+const html = '
vix replay
\n
vix replay replays a previously recorded Vix execution.
\n
It helps you reproduce a run that failed, crashed, or behaved unexpectedly. Use it when you want to rerun the same command without guessing what happened.
\n
\n
vix run does not record replay data by default.\nTo create a replay record, run your command with --replay.
vix replay loads a recorded execution from .vix/runs/ and runs it again with the stored context.
\n
It can:
\n
\n
replay the latest recorded run
\n
replay the latest failed run
\n
replay a specific run by id
\n
show recorded run details
\n
list previous runs
\n
clean recorded replay data
\n
append extra runtime arguments
\n
add temporary environment variables during replay
\n
\n
Recording a run
\n
Replay records are created only when vix run is executed with --replay.
\n
# Record a project run\nvix run api --replay\n\n# Record a built executable run\nvix run ./build-ninja/api --replay\n\n# Record a manifest run\nvix run app.vix --replay\n\n# Record a single-file C++ run\nvix run main.cpp --replay
Without --replay, vix run runs normally and does not create .vix/runs/.
\n
vix run api\nvix run main.cpp
These commands do not create replay data.
\n
Basic usage
\n
# Replay the latest recorded run\nvix replay\n\n# Replay the latest run explicitly\nvix replay last\n\n# Replay the latest failed run\nvix replay failed\n\n# Replay a specific run\nvix replay 2026-05-05-18-42-11-a91f
When to use it
\n
Use vix replay when an execution fails and you want to reproduce it quickly.
\n
Typical workflow:
\n
vix run api --replay\n# something fails\n\nvix replay failed
Or:
\n
vix run server.cpp --replay\n# unexpected result\n\nvix replay last
Why it matters
\n
Without replay, you often need to remember: which command was used, which directory it ran from, which arguments were passed, which environment variables were active, which output was produced, and whether the run failed, crashed, or was interrupted.
\n
vix replay keeps that context in a recorded run.
\n
Difference between vix run, vix dev, and vix replay
\n
\n\n
\n
Command
\n
Best for
\n
Records/replays context
\n
\n\n
\n
vix run
\n
manual run
\n
records only with --replay
\n
\n
\n
vix dev
\n
active development
\n
records development executions when enabled
\n
\n
\n
vix replay
\n
reproducing a previous run
\n
replays recorded execution
\n
\n
\n
vix replay does not replace vix run or vix dev. It uses recorded executions created by replay-enabled runs.
\n
Replay the latest run
\n
vix replay
Equivalent to:
\n
vix replay last
You can also use:
\n
vix replay latest
Replay the latest failed run
\n
vix replay failed
You can also use:
\n
vix replay fail
This is useful when several successful runs happened before or after a failure.
\n
Replay a specific run
\n
Each recorded run has an id:
\n
vix replay 2026-05-05-18-42-11-a91f
Run ids are stored under .vix/runs/.
\n
List recorded runs
\n
vix replay list\n\n# Show only failed runs\nvix replay list --failed\n\n# Show only successful runs\nvix replay list --success\n\n# Show only interrupted runs\nvix replay list --interrupted\n\n# Limit the number of results\nvix replay list --limit 10
Show a recorded run
\n
# Show the latest run\nvix replay show last\n\n# Show the latest failed run\nvix replay show failed\n\n# Show a specific run\nvix replay show 2026-05-05-18-42-11-a91f
This prints the recorded metadata, command, status, duration, logs, and replay hint.
\n
Dry run
\n
Use --dry-run to print the replay command without executing it:
\n
vix replay last --dry-run
Useful when you want to inspect what will be replayed before running it.
\n
Pass extra app arguments
\n
Arguments after -- are appended to the replay command:
\n
vix replay last -- --port 8080
Add environment variables
\n
vix replay last --env VIX_LOG_LEVEL=debug
Multiple variables:
\n
vix replay last --env VIX_LOG_LEVEL=debug --env APP_ENV=local
Use another replay directory
\n
By default, vix replay reads from .vix/runs/ in the current directory.
\n
Use --dir or --cwd to read from another location:
\n
vix replay last --dir ./api\nvix replay list --cwd ./api
vix run api --replay\nvix run ./build-ninja/api --replay\nvix run app.vix --replay\nvix run main.cpp --replay
List options
\n
\n\n
\n
Option
\n
Description
\n
\n\n
\n
--all
\n
Show all replay runs
\n
\n
\n
--failed, --fail
\n
Show failed replay runs
\n
\n
\n
--success, --ok
\n
Show successful replay runs
\n
\n
\n
--interrupted, --interrupt
\n
Show interrupted replay runs
\n
\n
\n
--limit <n>
\n
Limit number of rows
\n
\n
\n
--dir, --cwd <path>
\n
Use another directory containing .vix/runs
\n
\n
\n
Common workflows
\n
# Record and replay a project run\nvix run api --replay\nvix replay last\n\n# Record and replay a single-file C++ run\nvix run main.cpp --replay\nvix replay last\n\n# Replay the latest failed run\nvix replay failed\n\n# Inspect the latest run before replaying\nvix replay show last\nvix replay last\n\n# List failures\nvix replay list --failed\n\n# Replay with debug logs\nvix replay failed --env VIX_LOG_LEVEL=debug\n\n# Print the replay command only\nvix replay last --dry-run\n\n# Clean old replay data\nvix replay clean
Common mistakes
\n
Expecting vix run to record automatically
\n
Wrong:
\n
vix run api\nvix replay last
Correct:
\n
vix run api --replay\nvix replay last
vix run does not create replay records by default. Use --replay when you want the execution to be recorded.
\n
Running replay from the wrong directory
\n
Wrong:
\n
cd ..\nvix replay last
Correct:
\n
cd api\nvix replay last
Or:
\n
vix replay last --dir ./api
vix replay reads .vix/runs/ from the current directory unless --dir or --cwd is provided.
\n
Forgetting that failed means the latest failed run
\n
vix replay failed
This does not replay every failed run. It replays only the latest failed run.
\n
To list all failures:
\n
vix replay list --failed
Passing extra arguments without --
\n
Wrong:
\n
vix replay last --port 8080
Correct:
\n
vix replay last -- --port 8080
The -- separates replay options from arguments appended to the replayed command.
\n
Related commands
\n
\n\n
\n
Command
\n
Purpose
\n
\n\n
\n
vix run
\n
Build and run manually
\n
\n
\n
vix dev
\n
Start dev server with auto-reload
\n
\n
\n
vix build
\n
Configure and compile
\n
\n
\n
vix check
\n
Validate build, tests, runtime, and sanitizers
\n
\n
\n
vix tests
\n
Run tests
\n
\n
\n';
+const vixReplay = {
+ html
+};
+export {
+ vixReplay as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-run-DS13lFnX.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-run-DS13lFnX.js
new file mode 100644
index 000000000..3898b5dd6
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-run-DS13lFnX.js
@@ -0,0 +1,8 @@
+const html = '
vix run
\n
Technical notes about how vix run resolves files, scripts, projects, targets, CMake fallback, and runtime arguments.
This keeps the direct runner simple while still allowing richer scripts.
\n
Relationship with vix.app
\n
vix.app and script fallback are different features.
\n
vix.app is for projects.
\n
Script fallback is for single-file execution.
\n
But both can use generated CMake internally.
\n
The difference is source of truth:
\n
vix.app project:\n source of truth = vix.app\n\nscript fallback:\n source of truth = main.cpp + run options
Relationship with project mode
\n
Project mode should not use script fallback.
\n
If the user runs:
\n
vix run
inside a project, Vix should use project resolution.
\n
If the user runs:
\n
vix run main.cpp
Vix should use script mode.
\n
The explicit source file decides script mode.
\n
Explicit fallback flag
\n
It may be useful to let users force fallback.
\n
Example design:
\n
vix run main.cpp --cmake
or:
\n
vix run main.cpp --fallback cmake
This can help debug direct runner problems.
\n
The exact flag can evolve.
\n
Explicit no-fallback flag
\n
It may also be useful to disable fallback.
\n
Example design:
\n
vix run main.cpp --no-fallback
This helps test the direct runner.
\n
It also lets advanced users see whether a script can run without generated build infrastructure.
\n
Verbose output
\n
Verbose mode should show the selected strategy.
\n
Example:
\n
Running script: main.cpp\nMode: CMake fallback\nGenerated source: .vix/run/generated/main/\nBuild directory: .vix/run/build/main/\nTarget: main
This makes fallback behavior transparent without making normal output noisy.
\n
Common fallback mistakes
\n
Running from generated directory
\n
Wrong:
\n
program working directory = .vix/run/generated/main/
unless explicitly intended.
\n
Correct:
\n
working directory remains predictable for the user
Treating generated CMake as user project
\n
Wrong:
\n
source of truth = generated CMakeLists.txt
Correct:
\n
source of truth = main.cpp and run options
Falling back on real compile errors
\n
Wrong:
\n
syntax error -> fallback to CMake
Correct:
\n
syntax error -> show diagnostic
Hiding linker problems
\n
Wrong:
\n
all linker errors trigger fallback silently
Correct:
\n
fallback only when the missing link is a known direct-mode limitation
Good first implementation
\n
A good first CMake fallback can support:
\n
generate temporary CMakeLists.txt\nconfigure with Ninja\nbuild script executable\nrun with preserved stdin/stdout/stderr\nforward runtime arguments\nstore logs\nreuse configure when unchanged\nfallback only for known dependency cases
This gives Vix a reliable compatibility layer for scripts.
\n
Later improvements
\n
Later improvements can include:
\n
dependency-aware fallback selection\ncompiled module auto-linking\nregistry dependency integration\nobject cache import from fallback builds\nartifact cache for script executables\nbetter diagnostics from generated CMake\nexplicit fallback flags\nexplainable fallback reasons
The fallback can grow without changing the user command.
\n
Engineering principle
\n
The fallback should follow this principle:
\n
direct when possible\ngenerated CMake when necessary\nclear diagnostics always
This keeps script mode fast for simple cases and powerful for complex ones.
\n
Conclusion
\n
The CMake fallback exists because not every C++ script can be built safely with one direct compiler command.
\n
Some scripts need compiled modules, packages, or richer build metadata.
\n
Instead of forcing the user to create a project, Vix can generate an internal CMake project and build the script through the compatibility path.
\n
The user still runs:
\n
vix run main.cpp
The implementation chooses the right path:
\n
simple script -> direct runner\ncomplex script -> CMake fallback
That keeps C++ script execution simple from the outside while preserving the power needed for real-world dependencies.
\n';
+const vixRunCmakeFallback = {
+ html
+};
+export {
+ vixRunCmakeFallback as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-run-runtime-arguments-BMxNsraJ.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-run-runtime-arguments-BMxNsraJ.js
new file mode 100644
index 000000000..aa647bedf
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-run-runtime-arguments-BMxNsraJ.js
@@ -0,0 +1,8 @@
+const html = '
vix run Runtime Arguments
\n
vix run has two responsibilities.
\n
It must control Vix itself.
\n
It must also run the user program.
\n
Those two responsibilities create an important problem:
\n
Which arguments are for Vix?\nWhich arguments are for the program being executed?
For example:
\n
vix run main.cpp --name Gaspard
Does --name belong to Vix?
\n
Or does it belong to main.cpp?
\n
A good runtime argument design must answer this clearly.
A clear argument boundary makes vix run predictable, scriptable, and safe for real CLI programs.
\n';
+const vixRunRuntimeArguments = {
+ html
+};
+export {
+ vixRunRuntimeArguments as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-run-script-vs-project-mode-BLNI-8Cg.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-run-script-vs-project-mode-BLNI-8Cg.js
new file mode 100644
index 000000000..e85694bce
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vix-run-script-vs-project-mode-BLNI-8Cg.js
@@ -0,0 +1,8 @@
+const html = '
vix run Script Mode vs Project Mode
\n
vix run supports two different execution models:
\n
script mode\nproject mode
They solve different problems.
\n
Script mode is for quickly running one C++ file.
\n
Project mode is for building and running a real project.
\n
The command can look almost the same from the outside, but internally the flow is different.
\n
vix run main.cpp
uses script mode.
\n
vix run
inside a project uses project mode.
\n
Understanding the difference matters because vix run must know what to compile, where to place outputs, how to resolve dependencies, and how to pass arguments to the final program.
\n
Why two modes exist
\n
C++ has two common workflows.
\n
The first workflow is quick experimentation:
\n
I have one file.\nCompile it.\nRun it.
The second workflow is project execution:
\n
I have a project.\nBuild the target.\nRun the executable.
These workflows should not require the same setup.
\n
A single-file program should not need a CMakeLists.txt.
\n
A full project should not be treated like one loose source file.
That boundary keeps vix run simple from the outside and precise inside.
\n';
+const vixRunScriptVsProjectMode = {
+ html
+};
+export {
+ vixRunScriptVsProjectMode as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vue-fullstack-dev-workflow-BGprCW-h.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vue-fullstack-dev-workflow-BGprCW-h.js
new file mode 100644
index 000000000..9875c6380
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/vue-fullstack-dev-workflow-BGprCW-h.js
@@ -0,0 +1,8 @@
+const html = '
Vue frontend with a Vix C++ backend
\n
C++ is usually seen as a systems language.\nThat is true, but it does not mean C++ should stay far away from modern web development workflows.\nWith Vix.cpp v2.6.0, we started experimenting with a full-stack development workflow where a Vue frontend can run next to a Vix-powered C++ backend.\nThe idea is simple:
\n
Vue frontend\nVix C++ backend\nOne development workflow
The problem
\n
Modern frontend developers already have a strong workflow.\nThey use tools like Vue, Vite, hot reload, browser devtools, and fast feedback loops.\nC++ developers often have something very different:
Both worlds are powerful, but they are usually separated.\nVix is trying to reduce that gap.
\n
The new workflow
\n
A Vue + Vix project can be created with:
\n
vix new shop --template vue
This generates a project with:
\n
src/main.cpp Vix C++ backend\nfrontend/ Vue frontend\nfrontend/src/App.vue Vue application\nvix.app Vix application manifest\nvix.json project metadata and tasks
Then development starts with:
\n
vix dev
In this mode, Vix starts the backend and the Vue/Vite frontend together.\nThe frontend runs with Vite.\nThe backend runs with Vix.\nThe API stays powered by C++.
\n
Why Vue?
\n
Vue is simple, progressive, and approachable.\nThat matters because the goal is not to force frontend developers to abandon what they already know.\nThe goal is to give them a path into C++ without destroying their existing frontend experience.\nA developer can keep writing Vue components while using Vix for backend APIs, performance-sensitive logic, local-first systems, networking, storage, or runtime features.
\n
Why not put this in vix run?
\n
vix run should stay focused.\nIt runs the Vix application or target.\nFor a full development environment, the right command is:
\n
vix dev
That keeps the mental model clean:
\n
vix run run the Vix app\nvix dev run the development environment\nvix build build the project
So for Vue + Vix projects:
\n
vix run\n runs the Vix backend\n\nvix dev\n runs the Vix backend and Vue frontend\n\nvix build\n builds the application
API proxy
\n
During development, the Vue frontend can call:
\n
/api/*
Vite proxies those requests to the Vix backend:
\n
http://localhost:8080
So frontend code can stay simple:
\n
const response = await fetch("/api/hello");\nconst data = await response.json();
The browser talks to Vue.\nVue talks to /api.\nVix handles the backend.
\n
What this means for Vix.cpp
\n
This is not about replacing Vue.\nThis is not about replacing Vite.\nThis is about making Vix a better bridge between modern frontend workflows and C++ backend development.\nThe long-term direction is clear:
\n
Keep the frontend experience developers love.\nBring C++ closer to application development.\nMake the workflow simple enough to try in minutes.
Vix.cpp v2.6.0 is a step in that direction.
\n';
+const vueFullstackDevWorkflow = {
+ html
+};
+export {
+ vueFullstackDevWorkflow as default,
+ html
+};
diff --git a/vix-site/.vite-ssg-temp/1mc6wisw06/assets/why-vix-app-exists-uAZWuAmv.js b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/why-vix-app-exists-uAZWuAmv.js
new file mode 100644
index 000000000..8a37da589
--- /dev/null
+++ b/vix-site/.vite-ssg-temp/1mc6wisw06/assets/why-vix-app-exists-uAZWuAmv.js
@@ -0,0 +1,8 @@
+const html = '
Why vix.app Exists
\n
vix.app exists because starting a C++ project should not require writing a build system first.
\n
C++ gives you control, performance, and long-term stability. But the first step is often too heavy:
\n
create a folder\nwrite CMakeLists.txt\nchoose a generator\nconfigure the build\nunderstand targets\nunderstand include paths\nunderstand link libraries\nthen finally write code
For experienced C++ engineers, this is normal.
\n
For application developers, it is friction.
\n
vix.app is Vix.cpp’s answer to that friction.
\n
It is a small project manifest that lets a developer describe a C++ target directly.
\n
this is the target name\nthis is the target type\nthese are the source files\nthese are the include directories\nthese are the packages\nthese are the libraries\nbuild it\nrun it
The problem
\n
C++ does not have a single default application workflow.
\n
In many ecosystems, a new project starts with one command and one simple config file.
\n
In C++, even a small application often begins with build-system decisions.
\n
A minimal CMake project is already a small build-system program:
\n
cmake_minimum_required(VERSION 3.24)\n\nproject(hello LANGUAGES CXX)\n\nadd_executable(hello\n src/main.cpp\n)\n\ntarget_compile_features(hello PRIVATE cxx_std_20)
`);
+ _push(ssrRenderComponent(_component_RouterLink, {
+ class: "community-back",
+ to: "/"
+ }, {
+ default: withCtx((_, _push2, _parent2, _scopeId) => {
+ if (_push2) {
+ _push2(` ← Back to Home `);
+ } else {
+ return [
+ createTextVNode(" ← Back to Home ")
+ ];
+ }
+ }),
+ _: 1
+ }, _parent));
+ _push(`
Community
The Vix.cpp community is open. Anyone can create a space where people using or interested in Vix.cpp can meet, exchange ideas, share projects, and help each other.
This page lists the community spaces currently known around Vix.cpp. New local, language-specific, or online communities can be added as they appear.
General discussion
Discord
Vix.cpp Community
Talk about Vix.cpp, ask questions, share projects, exchange ideas, and meet other people interested in C++ development.