Vix.cpp v2.1.17

Vix.cpp v2.1.17 is a CMake package compatibility release focused on SQLite dependency resolution in exported WebSocket builds. This 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.

SQLite target mismatch

The main fix in Vix.cpp v2.1.17 is resolving the SQLite target mismatch in the exported WebSocket module. Previously, 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. Vix.cpp v2.1.17 improves this by ensuring the SQLite dependency is resolved before Vix targets are loaded.

VixConfig.cmake dependency handling

This release adds proper SQLite dependency handling in VixConfig.cmake.

The package configuration now calls the required dependency discovery path before loading exported Vix targets. This prevents missing target errors during:

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.

SQLite target normalization

Vix.cpp v2.1.17 improves SQLite target naming across modules and package configuration.

The release standardizes on:

SQLite3::SQLite3

as the canonical SQLite target, while also adding compatibility aliases for common alternatives such as:

SQLite::SQLite3

and:

sqlite3

This makes the package more tolerant of different environments, package managers, and CMake discovery behavior.

WebSocket dependency reliability

The WebSocket module now has stronger SQLite target resolution logic. This 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. For developers, the practical result is simpler: running programs that depend on WebSocket should no longer fail because of missing transitive SQLite targets.

Developer experience

This release eliminates a common vix run configuration failure. Simple 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. This is especially important for a runtime-focused CLI, where users expect vix run to handle the project environment consistently.

Highlights

  • Fixed SQLite target mismatch in the exported WebSocket module.
  • Fixed cases where vix::websocket exposed SQLite3::SQLite3 without guaranteeing the target existed.
  • Added proper SQLite dependency resolution before loading Vix targets.
  • Improved VixConfig.cmake dependency handling.
  • Standardized SQLite target naming around SQLite3::SQLite3.
  • Added compatibility aliases for SQLite::SQLite3 and sqlite3.
  • Strengthened WebSocket SQLite target resolution logic.
  • Improved support for vcpkg, system packages, and manual SQLite installs.
  • Eliminated common vix run failures caused by missing transitive SQLite dependencies.

Compatibility

Vix.cpp v2.1.17 introduces no breaking changes. Existing projects remain compatible. The 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.

Notes

Vix.cpp v2.1.17 is a focused package reliability release. It 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. For a C++ runtime ecosystem, this kind of fix is essential because package configuration must be predictable before higher-level workflows can feel reliable.