Vix.cpp v2.1.1

Vix.cpp v2.1.1 is a small but important registry and CMake stability release. This 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. The 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.

Dependency manifest compatibility

The main fix in Vix.cpp v2.1.1 is support for the deps fallback when loading package manifests. vix install now correctly resolves dependencies declared using both:

"dependencies"

and:

"deps"

This improves compatibility with mixed package formats and ensures dependencies are resolved in the correct topological order. The recommended field remains dependencies, but deps continues to be supported for compatibility.

Stable dependency loading order

This release fixes dependency loading order in:

.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. For 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. This 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.

Registry-safe generated CMake

Vix.cpp v2.1.1 improves generated CMakeLists.txt files for application projects. Generated CMake now safely includes:

.vix/vix_deps.cmake

only when the file exists. This allows developers to create a project, build it without registry packages, then add registry packages later without breaking the CMake configuration. The generated CMake also introduces:

vix_link_optional_targets(...)

This helper makes it easier to link optional registry libraries only when their targets are available.

Inline guidance for registry packages

Generated application CMake files now include clearer inline guidance for linking registry libraries. This helps users understand where registry dependencies should be linked and how optional package targets should be handled. That 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. Vix.cpp v2.1.1 makes that boundary easier to understand.

Consistency between install, build, and run

This release improves consistency between:

vix install
vix build
vix run

The dependency resolver, generated CMake files, and runtime build behavior now handle mixed package formats more reliably. That matters because a package workflow should not behave differently depending on whether the user installs dependencies, builds the project, or runs the application.

Highlights

  • Added deps fallback support when loading package manifests.
  • Preserved support for the recommended dependencies field.
  • Improved topological dependency ordering in vix install.
  • Stabilized dependency loading order in .vix/vix_deps.cmake.
  • Fixed missing target errors for dependent packages.
  • Improved generated CMakeLists.txt safety for registry packages.
  • Safely includes .vix/vix_deps.cmake only when present.
  • Added vix_link_optional_targets(...).
  • Added inline guidance for linking registry libraries.
  • Improved resilience for mixed package formats.
  • Improved consistency between vix install, vix build, and vix run.

Compatibility

Vix.cpp v2.1.1 introduces no breaking changes. Existing projects remain compatible. Package manifests should standardize on:

"dependencies"

but the older deps field remains supported. Projects using the Vix registry with CMake should now behave more reliably, especially when dependencies depend on each other.

Notes

Vix.cpp v2.1.1 is a small release, but it fixes an important class of stability problems. Registry 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. Small release. Big stability upgrade.