Vix.cpp v2.1.12

Vix.cpp v2.1.12 is an SDK stabilization and CMake export reliability release. This 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.

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.

Export-safe JSON integration

The main fix in Vix.cpp v2.1.12 is making nlohmann_json integration export-safe. Previous JSON integration could expose non-exported targets through the installed package graph. That could cause CMake export failures or break consumer projects after installation. Vix.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. This makes the JSON module safer to consume through installed SDK packages.

SQLite target normalization

The WebSocket module now uses normalized SQLite target handling. This release replaces deprecated usage of:

SQLite::SQLite3

with the canonical target:

SQLite3::SQLite3

Compatibility aliases are also added for cross-platform builds. This 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.

CMake export fixes

Vix.cpp v2.1.12 fixes install(EXPORT VixTargets) issues caused by non-exported dependencies. This 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. This release strengthens the export graph so installed Vix packages are usable through:

find_package(Vix)

SDK installability

This release improves SDK installability. Generated SDK artifacts are now fully usable after installation without missing dependencies from JSON or SQLite backends. This 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. Vix.cpp v2.1.12 makes that workflow more reliable.

Cross-platform dependency consistency

Dependency handling is now more consistent across Linux, macOS, and Windows. This applies especially to SQLite and JSON backends, where package discovery and target naming can differ between environments. Vix.cpp v2.1.12 improves those paths so the same installed SDK behaves more predictably across platforms.

Highlights

  • Made nlohmann_json integration export-safe.
  • Removed direct linkage to non-exported JSON targets.
  • Fixed header-only JSON fallback behavior with install and export flows.
  • Normalized SQLite target usage in the WebSocket module.
  • Replaced deprecated SQLite::SQLite3 usage with SQLite3::SQLite3.
  • Added SQLite compatibility aliases for cross-platform builds.
  • Fixed install(EXPORT VixTargets) errors.
  • Improved CMake package reliability.
  • Improved find_package(Vix) usage for consumer projects.
  • Improved SDK installability after artifact generation.
  • Unified dependency handling across Linux, macOS, and Windows for SQLite and JSON backends.

Compatibility

Vix.cpp v2.1.12 introduces no breaking changes. Existing projects remain compatible. The main difference is that installed SDK artifacts should now work more reliably through find_package(Vix) without missing JSON or SQLite dependency targets. Projects using WebSocket, JSON, or installed Vix SDK packages should benefit from more stable CMake configuration behavior.

Notes

Vix.cpp v2.1.11 introduced SDK packaging. Vix.cpp v2.1.12 stabilizes the CMake export layer and makes Vix more reliable as a reusable installed SDK. This 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.