Vix.cpp v2.7.4

Vix.cpp v2.7.4 makes specialized SDK profiles composable.

A project can now use modules from several installed profiles, such as web and data, without installing the complete all SDK. Before configuring CMake, Vix examines the project’s vix::* dependencies, determines which installed profiles provide them, and prepares one coherent SDK package for the build.

The release also improves the failure path when a project requests a known Vix module whose provider profile is not installed. Instead of allowing CMake to fail later with an unresolved target, the CLI identifies the missing module, reports its provider profile, and gives the exact installation command.

Release focus

SDK profiles were introduced to avoid requiring every developer to install the full Vix SDK.

A backend application may need the web profile, a database-oriented tool may need data, and a desktop or game project may use another specialized profile. This keeps installations smaller and gives each project a more focused development environment.

The original profile model worked well when a project remained inside one profile. The problem appeared when an application crossed that boundary.

A Cloud service, for example, may use WebSocket support from web together with database functionality from data:

target_link_libraries(
  cloud
  PRIVATE
    vix::db
    vix::websocket
)

Installing both profiles did not solve the problem by itself. Each profile provided an independent CMake package named Vix, and CMake does not merge several packages returned by separate find_package(Vix) calls.

Vix.cpp v2.7.4 addresses this at the CLI level. It treats installed profiles as components of one SDK environment and creates a local composed package when the project needs more than one of them.

Composing installed SDK profiles

The following workflow now supports a project that uses both web and data modules:

vix upgrade --sdk web data
vix install
vix build --preset release

The project does not need the heavier all profile merely because it links modules from two specialized profiles.

Before CMake configuration begins, vix build scans the project for known Vix targets. It resolves each requested module to the profile that provides it and verifies that the required profile is installed.

For this project:

target_link_libraries(
  app
  PRIVATE
    vix::db
    vix::websocket
)

Vix resolves:

vix::db          data
vix::websocket   web

Because more than one provider is required, the CLI generates a composed SDK package inside the build directory and passes it to CMake through Vix_DIR.

The project continues to use the normal public target names. SDK composition is an implementation detail handled by vix build.

Why `CMAKE_PREFIX_PATH` was not enough

Each installed SDK profile contains its own package configuration:

VixConfig.cmake
VixTargets.cmake

All profiles use the same CMake package name because they represent different installations of Vix rather than unrelated libraries.

Adding the web and data installation roots to CMAKE_PREFIX_PATH does not cause CMake to combine their targets. find_package(Vix) selects one package location and loads the configuration found there.

As a result, the first selected profile could expose vix::websocket while leaving vix::db unresolved, or expose vix::db while omitting vix::websocket.

Vix now resolves the profiles before invoking CMake and presents them through one generated package. The composed configuration contains the targets required by the project while preserving the installation paths and exported properties of their original profiles.

Automatic SDK profile selection

Developers do not need to declare the required SDK profile separately in the build command.

vix build scans the project’s CMake files and Vix manifests for known vix::* targets before configuration. It then maps those targets to the profiles that officially provide them.

The supported profile set is:

default
web
data
desktop
p2p
game
agent
all

When every requested module belongs to one profile, Vix uses that installed SDK directly.

When the project requires modules from several profiles, Vix creates a composed package for that build.

This keeps the SDK decision connected to the actual project dependencies. A project that starts with web and later adds vix::db can be built after installing data, without manually changing a separate SDK configuration file.

Shared SDK profile metadata

The CLI now uses one shared source of truth for SDK profile information.

Previously, the metadata displayed by:

vix upgrade --sdk info

and the metadata used internally by vix build could evolve through separate code paths. That created a risk that one command would describe a profile differently from the way another command resolved it.

Profile names, provided modules, descriptions, and provider relationships now come from a shared CLI helper.

This means the information shown to the developer and the information used during build resolution follow the same model.

It also makes later profile changes easier to maintain because a module should not need to be registered independently in several commands.

Exported SDK aliases

Some public Vix targets are aliases in the source tree.

During CMake export, aliases are not installed as ordinary targets. The underlying implementation target is exported, but the public alias used by consumer projects may need to be recreated in VixConfig.cmake.

Vix.cpp v2.7.4 restores the missing public aliases for:

vix::time
vix::conversion
vix::validation
vix::webrpc

This ensures that installed SDK consumers can use the same public target names that are available inside the Vix source tree.

The composed SDK generator preserves these aliases as well, so projects behave consistently whether they use one profile directly or several profiles through a generated composition.

Imported target paths

CMake export files commonly describe installed paths relative to an internal variable named _IMPORT_PREFIX.

A target may reference locations such as:

${_IMPORT_PREFIX}/include
${_IMPORT_PREFIX}/lib/libvix_websocket.a

That variable normally points to the root of the SDK installation that owns the target.

When a target from a secondary profile is copied into a composed configuration, leaving _IMPORT_PREFIX unresolved or binding it to the composed package directory can produce invalid paths such as:

/include
/lib/libvix_websocket.a

Vix now rewrites every _IMPORT_PREFIX occurrence to the installation root of the source profile before adding the target to the composed package.

A target imported from web therefore continues to resolve its headers and libraries from the installed web SDK, while a target imported from data resolves against the data installation.

This applies to all occurrences in the exported target definition, not only the first path encountered.

Project-generated targets

Not every target using the vix:: namespace represents an installed SDK module.

Vix can generate project-specific helper targets such as:

vix::deps

These targets describe the current project’s resolved dependencies and are created during project generation. They are not modules provided by an installed SDK profile.

The SDK resolver now excludes these generated targets when scanning project files.

Without this distinction, vix build could report that a profile was missing for a target that no profile was ever supposed to provide.

The resolver therefore considers only known public SDK modules when deciding which profiles are required.

Missing SDK diagnostics

When a project requests a known Vix module whose provider profile is not installed, the CLI now reports the problem before CMake configuration.

For example, a project may link:

target_link_libraries(app PRIVATE vix::websocket)

while only the data SDK is installed.

Vix now reports:

Missing SDK modules:
  vix::websocket  provider profile: web

install command:
  vix upgrade --sdk web

This is more useful than the generic CMake error:

Target "app" links to:
  vix::websocket
but the target was not found.

The CMake message identifies the unresolved target but does not know which Vix SDK profile provides it or how the developer should install that profile.

The new diagnostic keeps the failure at the level where it can be explained accurately.

Incompatible profile versions

Installed profiles used in the same composed SDK must come from the same Vix version.

For example, Vix will not compose a web profile from one release with a data profile from another release merely because both contain valid CMake packages.

Targets from different releases may have incompatible dependencies, export layouts, compile definitions, or module interfaces. Combining them could create a package that configures successfully but fails later in less predictable ways.

Vix checks the installed profile versions before generating the composed SDK. When the versions differ, the build stops and reports the incompatibility.

The developer can then upgrade the required profiles to the same Vix release before rebuilding.

Vix does not generate a partial package or silently choose one version over another.

Installation order independence

SDK composition does not depend on the order in which profiles were installed.

These installation sequences must describe the same environment:

vix upgrade --sdk web
vix upgrade --sdk data

and:

vix upgrade --sdk data
vix upgrade --sdk web

Provider selection is based on shared profile metadata and project requirements rather than directory discovery order.

This matters because SDK installations may be accumulated over time. A developer should not need to remember which profile was installed first or reinstall profiles in a particular sequence to obtain a valid composed package.

Choosing between profiles and `all`

The all profile remains useful when a developer intentionally wants the complete Vix SDK available in one installation.

It can be appropriate for SDK development, broad experimentation, release validation, examples that cover many unrelated modules, or environments where installation size is not a concern.

Projects with focused requirements no longer need all merely to cross one profile boundary.

A service using vix::websocket and vix::db can install web and data. A project using only web modules can continue to install web alone.

The choice is therefore based on the project’s real module requirements rather than a limitation of the package configuration system.

Regression coverage

Vix.cpp v2.7.4 adds tests for direct and composed SDK usage.

Web profile coverage includes projects using:

vix::websocket
vix::requests
vix::middleware

Data profile coverage includes:

vix::db
vix::orm
vix::cache
vix::kv

Combined profile coverage includes a project linking both:

vix::db
vix::websocket

The test suite also covers:

separate profile installation state;
profile installation order independence;
automatic module-to-profile resolution;
generation of the composed VixConfig.cmake;
restoration of exported public aliases;
_IMPORT_PREFIX rewriting;
exclusion of project-generated targets;
missing provider diagnostics;
incompatible installed profile versions;
suppression of the generic unresolved-target failure for known Vix modules.

These tests verify both successful composition and the cases where Vix must stop before invoking CMake.

Documentation

The CLI documentation now explains how installed SDK profiles participate in builds.

It covers:

installing more than one specialized profile;
automatic selection from project vix::* targets;
composition of multiple installed profiles;
version compatibility requirements;
missing-module diagnostics;
provider profile resolution;
the role of the all profile.

The documentation also clarifies that installing several SDK roots is not enough for CMake to merge them automatically. Composition is performed by vix build because the CLI has the project context and profile metadata required to build one valid package configuration.

Compatibility

Projects using one SDK profile continue to use that profile directly.

Existing project CMake files do not need to declare profile names. They continue to link public targets such as:

target_link_libraries(
  app
  PRIVATE
    vix::requests
    vix::websocket
)

Projects that already use the all SDK remain compatible.

Projects using modules from several specialized profiles can now install only the profiles they need. Their installed profiles must come from the same Vix version.

The generated composed SDK is local to the build directory. It does not modify the installed profile packages or merge their files permanently on disk.

Release summary

Vix.cpp v2.7.4 turns specialized SDK profiles into a composable installation model.

Projects can combine web, data, and other supported profile modules while keeping their SDK installation focused. vix build discovers the required modules from the project, resolves their provider profiles, verifies version compatibility, and generates one CMake package when composition is needed.

The release also restores missing public aliases, preserves imported target paths across profile boundaries, ignores project-generated helper targets, and replaces generic CMake failures with diagnostics that identify the missing module and its provider.

This makes SDK profiles practical for projects that do not fit entirely inside one category without forcing every developer to install the full Vix SDK.