Vix.cpp v2.6.2
Vix.cpp v2.6.2 is a workflow reliability release.
This release focuses on the parts of Vix.cpp that developers touch every day:
- running generic CMake projects
- installing dependencies
- updating dependencies
- listing dependencies
- checking outdated packages
- publishing packages
- preparing registry state
- reading build and test diagnostics
- using
vix.app - installing the Windows SDK
- exposing security-sensitive crypto helpers
The goal of v2.6.2 is not to add a large new runtime surface.
The goal is to make the existing Vix.cpp workflow more correct, more predictable, and easier to trust.
Release focus
The main focus of Vix.cpp v2.6.2 is dependency and registry workflow correctness.
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.
This release improves:
vix installvix updatevix outdatedvix listvix publish- registry dependency propagation
- generated CMake integration
- stale dependency link handling
- lockfile metadata updates
- package hash refresh behavior
It also improves vix run for generic CMake projects and strengthens diagnostics across build, test, and vix.app workflows.
Crypto security helpers
Vix.cpp v2.6.2 adds two important helpers to the crypto module.
The first addition is constant-time byte comparison helpers.
These are useful for security-sensitive comparisons where normal byte comparison may leak timing information.
The second addition is PBKDF2-HMAC-SHA256 password hashing and verification helpers.
This gives the crypto module a stronger foundation for password-related workflows.
The added capabilities are:
- constant-time byte comparison
- PBKDF2-HMAC-SHA256 password hashing
- PBKDF2-HMAC-SHA256 password verification
This is a small API addition, but it matters because security-sensitive helpers should be easy to use correctly.
vix run for generic CMake projects
vix run receives an important fix for generic CMake projects.
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.
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.
This makes vix run more useful for existing CMake projects that were not created by Vix.
The default vix run output is also kept cleaner during normal execution.
This matters because vix run should be readable during daily development, not noisy by default.
Smarter vix update behavior
vix update receives several important dependency workflow fixes.
The command now updates only dependencies with newer resolved versions instead of reprocessing every dependency in the project.
It also respects the version constraints declared in vix.json instead of always resolving direct dependencies to the latest registry version.
That distinction is important.
A dependency update command should not ignore the project’s declared version policy.
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.
v2.6.2 also improves vix update so it can refresh lockfile metadata and package hashes even when dependency versions do not change.
This allows the lockfile to stay accurate without pretending that a version update happened.
Update summaries are now clearer because they separate:
version changes
lockfile metadata updatesAlready-current dependencies are no longer repeated in the main update summary.
The result is a cleaner and more accurate dependency update experience.
Better vix outdated and vix list output
vix outdated now shows only direct project dependencies from vix.json by default.
The full locked dependency graph is still available with:
vix outdated --allThis improves the default view because most developers first want to know whether the dependencies they directly declared are outdated.
The same model was applied to vix list.
By default, vix list now shows only direct project dependencies from vix.json.
To show transitive locked dependencies, use:
vix list --allv2.6.2 also adds pagination and JSON output support to vix list.
This makes dependency inspection more useful for both humans and tools.
Cleaner vix install output
vix install output is now more accurate.
It reports only dependencies that were actually installed or relinked instead of counting every dependency from vix.lock as newly installed.
This makes the install summary more honest.
If nothing meaningful changed, the command should not make it look like every dependency was installed again.
Dependency installation messages are also shorter and cleaner.
This improves the developer experience, especially in projects with several dependencies or transitive packages.
Stale dependency link handling
v2.6.2 improves project dependency installation by handling stale or broken .vix/deps links more reliably.
This matters because project-local dependency links can become stale after:
- moving a project
- deleting dependency stores
- switching branches
- changing registry versions
- cleaning local build state
- interrupting previous installs
The install workflow now handles these cases more defensively.
The goal is simple:
if dependency links are stale,
Vix should repair them instead of leaving the project broken.Transitive registry dependency propagation
This release fixes transitive registry dependency propagation.
Packages such as rix/rix can now expose dependencies such as:
rix/csv
rix/debug
rix/authwithout requiring every application to list those dependencies manually.
This is important for the Vix registry model.
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.
This improves the userland package workflow and makes packages such as Rix easier to consume.
Registry workflow tested with Pico
v2.6.2 includes improvements made after testing the registry install, update, and generated CMake integration flow in production with:
pico.vixcpp.comThis matters because registry workflow issues are easiest to find in real package usage.
The release improves the registry dependency workflow based on that production-style validation.
The direction is clear:
registry metadata
-> resolved dependencies
-> lockfile
-> generated CMake integration
-> working C++ projectThe registry workflow must be reliable across all of those steps.
vix publish improvements
vix publish receives several fixes and diagnostic improvements.
The command now gives better diagnostics when a tag exists locally but has not been pushed to origin.
This is important because publishing a package usually depends on Git tags being visible remotely.
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.
This reduces false publish failures caused by old local state.
Publishing should fail because of a real package problem, not because the local registry checkout is stale or dirty.
Windows SDK release pipeline
v2.6.2 fixes the Windows SDK release pipeline.
The release now ensures that:
vix-sdk-windows-x86_64.zipis built, packaged, checksummed, signed, and uploaded to GitHub Releases.
This also fixes the Windows installer failure where install.ps1 attempted to download:
vix-sdk-windows-x86_64.zipbut the asset was missing from the release.
This is an important packaging fix.
A working installer depends on a complete release artifact pipeline.
If the installer expects an asset, the release process must always publish that asset.
Better CMake diagnostics
v2.6.2 improves CMake error parsing.
Multi-line:
message(FATAL_ERROR ...)diagnostics are now displayed clearly instead of being collapsed into unreadable one-line reasons.
This matters because CMake errors often contain important context across multiple lines.
A build tool should preserve that structure when reporting the failure.
The goal is not to hide CMake.
The goal is to make CMake failures easier to understand.
Better verbose build behavior
vix build -v is now kept readable.
Raw CMake/Ninja output is reserved for:
vix build --cmake-verboseThis gives developers two useful levels of output:
-v
readable Vix-level verbose output
--cmake-verbose
raw CMake/Ninja outputThat separation matters because normal verbose mode should help developers understand what Vix is doing without flooding the terminal.
When raw build-system logs are needed, they are still available explicitly.
Better vix tests failure diagnostics
vix tests receives improved failure diagnostics.
Test runner output is now summarized with:
- clearer failed test names
- source locations
- focused error messages
- compact code frames
This improves the debugging loop.
When tests fail, the developer should quickly see:
which test failed
where it failed
what the focused error was
which code frame mattersThis is especially important as Vix.cpp continues to expand module-level tests and CI coverage.
vix.app diagnostics
v2.6.2 improves diagnostics for vix.app projects.
If .vix/vix_deps.cmake is missing, Vix now reports a clearer error.
Resource validation also improves.
Missing resources now fail early with a clear error instead of failing later through a long post-build CMake command.
This is important because vix.app exists to make simple application projects easier.
When something is wrong, the error should point directly to the missing resource or missing generated dependency file.
Build toolchain behavior
This release fixes build toolchain behavior by using absolute system archiver paths.
This improves reliability in environments where tool lookup, PATH configuration, or build generator behavior can otherwise produce inconsistent results.
Small toolchain fixes like this help make builds more reproducible.
Middleware public header improvements
v2.6.2 exposes middleware app integration helpers through the public aggregate header.
It also keeps the middleware aggregate header cache independent.
This improves the public middleware integration surface and keeps include behavior cleaner.
Highlights
Added constant-time byte comparison helpers to the crypto module.
Added PBKDF2-HMAC-SHA256 password hashing helpers.
Added PBKDF2-HMAC-SHA256 password verification helpers.
Fixed
vix runfor generic CMake projects by detecting the executable produced by the build.Kept default
vix runoutput cleaner during normal execution.Fixed
vix updateso it updates only dependencies with newer resolved versions.Fixed
vix updateso it respects version constraints declared invix.json.Improved
vix updateso it can refresh lockfile metadata and package hashes even when dependency versions do not change.Improved
vix updatesummaries by separating version changes from lockfile metadata updates.Improved
vix outdateddefault output to show only direct project dependencies.Added
vix outdated --allsupport for the full locked dependency graph.Improved
vix listdefault output to show only direct project dependencies.Added
vix list --allsupport for transitive locked dependencies.Added pagination and JSON output support to
vix list.Fixed
vix installoutput so it reports only dependencies that were actually installed or relinked.Shortened and cleaned dependency installation messages.
Fixed stale and broken
.vix/depslink handling.Fixed transitive registry dependency propagation for packages such as
rix/rix.Improved
vix publishdiagnostics when a tag exists locally but has not been pushed toorigin.Fixed
vix publishregistry preparation for stale publish branches and untracked registry entries.Improved registry install, update, and generated CMake integration after production testing with
pico.vixcpp.com.Fixed the Windows SDK release pipeline.
Fixed the Windows installer failure caused by a missing
vix-sdk-windows-x86_64.ziprelease asset.Improved CMake error parsing for multi-line
message(FATAL_ERROR ...)diagnostics.Improved
vix build -vreadability.Reserved
--cmake-verbosefor raw CMake/Ninja output.Improved
vix testsfailure diagnostics with clearer names, locations, messages, and code frames.Improved
vix.appdiagnostics when.vix/vix_deps.cmakeis missing.Improved
vix.appresource validation so missing resources fail early.Fixed build toolchain behavior by using absolute system archiver paths.
Exposed middleware app integration helpers through the public aggregate header.
Kept middleware aggregate header cache independent.
Compatibility
Vix.cpp v2.6.2 does not introduce intentional breaking changes.
Existing project workflows continue to work:
vix build
vix run
vix dev
vix tests
vix install
vix updateThe main behavior changes are correctness and output improvements.
For dependency workflows, default views are now more focused:
vix list
vix outdatedshow direct dependencies by default.
Use:
vix list --all
vix outdated --allwhen you need the full locked dependency graph.
For build output, use:
vix build -vfor readable Vix verbose output.
Use:
vix build --cmake-verbosewhen raw CMake/Ninja output is needed.
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.
Notes
Vix.cpp v2.6.2 is a practical release.
It improves the workflows that make Vix usable every day:
install
update
list
outdated
publish
run
build
test
package
diagnoseIt also strengthens the registry model, improves Windows release packaging, adds useful crypto helpers, and makes diagnostics easier to read.
This release is another step toward a more dependable C++ application platform.
The direction remains the same:
native C++
modern workflow
reliable dependency management
clear diagnostics
production-oriented toolingVix.cpp v2.6.2 makes that foundation cleaner and more predictable.