Vix.cpp v2.7.5

Vix.cpp v2.7.5 fixes two problems that affected existing projects rather than introducing a new developer-facing feature.

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.

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.

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.

Release focus

Vix SDK profiles allow developers to install only the parts of the platform required by a project.

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.

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.

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.

Vix.cpp v2.7.5 addresses both cases by making SDK composition provider-aware and making integrity migration evidence-based.

Composed SDK profiles

SDK profiles are generated independently and can then be combined into a single installation.

For example:

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.

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.

This keeps the generated CMake namespace aligned with the real SDK exports and avoids ambiguous ownership when profiles overlap.

Provider-aware target resolution

The validation module exposed one of the composition errors fixed in this release.

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.

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.

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.

By preserving that boundary, composed SDKs behave like the individual profiles from which they were built.

Exact target property preservation

Composed targets now preserve the exact exported properties of their provider SDK target.

These properties can include:

INTERFACE_INCLUDE_DIRECTORIES
INTERFACE_LINK_LIBRARIES
INTERFACE_COMPILE_DEFINITIONS
INTERFACE_COMPILE_OPTIONS
INTERFACE_LINK_OPTIONS

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.

This matters because exported CMake targets are more than names. Their interface properties describe how consumer projects compile and link against the SDK.

A composed target that points to the right module but carries the wrong interface properties is still incorrect.

Target property isolation

This release also fixes how target properties are extracted during SDK generation.

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.

For example, properties from:

vix::db

could leak into:

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.

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.

This makes composed SDK output deterministic and equivalent to the provider SDK exports.

Old lockfile integrity metadata

Vix lockfiles record the exact package version and source state selected for a project.

Modern lockfiles use canonical package integrity metadata based on:

vix-package-sha256
hash 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.

Previously, resolving this situation could require a manual sequence such as:

vix registry sync
vix update
vix 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.

Vix.cpp v2.7.5 performs that migration during vix install when all required safety conditions are satisfied.

Canonical integrity migration

When vix install encounters obsolete package integrity metadata, it verifies the complete identity of the locked dependency before modifying the lockfile.

A successful migration updates only:

hash
hash_algorithm
hash_version

The locked package id, selected version, tag, commit, source, and dependency resolution remain unchanged.

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.

After migration, subsequent vix install runs use the canonical v2 metadata normally.

Automatic registry synchronization

Integrity migration may require registry metadata that is not available in the local registry checkout.

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.

This synchronization is performed only when it is required to validate the locked package. It does not turn installation into a general package update.

The workflow becomes:

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.

This keeps installation responsible for making the locked project installable without silently changing the versions selected by that lockfile.

Migration safety

Automatic migration is allowed only when every available source of package identity agrees.

Vix verifies that:

  • the locked package id matches the registry package;
  • the locked version matches the registry version;
  • the recorded tag matches;
  • the recorded commit matches;
  • the registry metadata describes the same package source;
  • the local checkout corresponds to the locked package;
  • the checkout contains the expected package content;
  • the checkout is clean.

Only after these checks succeed does Vix calculate the canonical v2 package hash and update the integrity fields.

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.

Cases that still fail

vix install continues to fail without rewriting the lockfile when the dependency state cannot be proven safe.

A dirty checkout is rejected because local modifications mean the package content no longer corresponds exactly to the locked source.

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.

Incomplete checkouts are rejected because Vix cannot calculate a trustworthy canonical package hash when expected files are missing.

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.

This distinction is central to the safety model:

obsolete format + verified identity = migrate
modern format + incorrect hash      = fail

Automatic migration repairs compatibility metadata. It does not weaken integrity validation.

Idempotent lockfile behavior

After a successful migration, running vix install again does not modify the lockfile.

The package now contains canonical integrity fields, so the normal verification path can compare the stored v2 hash directly with the installed content.

This idempotence matters for source control and automated builds. A project should not produce repeated lockfile changes every time dependencies are installed.

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.

Softadastra Cloud validation

The migration was validated against Softadastra Cloud as a real consumer project.

The project dependencies were installed with:

vix install

No manual registry synchronization or dependency update was required.

The project was then built with:

vix build --preset release

The release build completed successfully and produced:

bin/cloud

This validation covered a project using multiple Vix modules and a composed SDK rather than an isolated package fixture.

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.

Regression coverage

Vix.cpp v2.7.5 adds regression tests for the SDK composition and lockfile migration paths.

The SDK tests cover:

  • aliases generated only by the correct provider profile;
  • vix::validation resolution in a web + data installation;
  • preservation of provider target properties;
  • isolation between unrelated target property blocks;
  • prevention of vix::db properties leaking into vix::websocket.

The package integrity tests cover:

  • registry-backed migration from obsolete hash metadata;
  • automatic registry synchronization;
  • canonical v2 metadata generation;
  • lockfile idempotence after migration;
  • rejection of dirty local checkouts;
  • rejection of registry commit mismatches;
  • rejection of incomplete checkout state;
  • rejection of incorrect modern v2 hashes.

These tests focus on the boundaries where an automatic repair must stop and return an error.

Compatibility

Projects using a single SDK profile continue to use the same public CMake targets.

Projects combining profiles such as web and data should receive more accurate target aliases and interface properties without changing their CMakeLists.txt.

Existing lockfiles using current vix-package-sha256 v2 metadata are not migrated. They continue through the normal integrity verification path.

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.

Projects with intentionally modified dependency checkouts must clean, restore, or explicitly update those dependencies before installation can continue.

Release summary

Vix.cpp v2.7.5 improves the reliability of existing Vix projects in two areas where generated metadata must be exact.

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.

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.

The result is a more predictable SDK for multi-profile projects and a safer upgrade path for projects created with earlier Vix lockfile formats.