From eca06bf9a5173936c58fefcb69ab678d451dd2e8 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Sat, 8 Aug 2026 11:17:21 +0300 Subject: [PATCH 01/19] fix: prepare v2.8.4 run regression fixes --- .gitignore | 1 + CHANGELOG.md | 18 +++++++++++++++++- modules/cli | 2 +- 3 files changed, 19 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index d227cc6..4a21a8c 100644 --- a/.gitignore +++ b/.gitignore @@ -54,6 +54,7 @@ cmd.txt # ====================================================== scripts/changelog-release.sh scripts/update_changelog.sh +scripts/publish-markdown-issues.sh # ====================================================== # πŸ”§ Local test & reference builds diff --git a/CHANGELOG.md b/CHANGELOG.md index 5902278..ffbfd65 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,7 +5,23 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). -# Vix v2.8.0 +# Vix v2.8.4 + +## Fixed + +### `vix run` stability and performance + +This release fixes important regressions introduced in v2.8.3. + +- Standalone C++ scripts no longer enable ASan and UBSan implicitly. +- Vix runtime scripts now use the reliable CMake fallback link path. +- Linker errors now preserve missing symbols and provide clearer diagnostics with source locations and actionable hints. +- Failed Direct script builds are cached and replayed without recompiling when the build fingerprint has not changed. +- Negative-cache tracing now correctly reports matching failure metadata. + +v2.8.4 restores fast and reliable standalone C++ execution while keeping explicit sanitizer support unchanged. + +# Vix v2.8.3, v2.8.2, v2.8.1 ## Added diff --git a/modules/cli b/modules/cli index ae6d75a..6a25c16 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit ae6d75a99ad52284777a380bf34dbf2afe6f2491 +Subproject commit 6a25c166e7b6c396339334901b976fceb5298cc5 From cd083efd181e485609d493a1cec43c342b18568b Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Sat, 8 Aug 2026 13:10:32 +0300 Subject: [PATCH 02/19] feat: add live build progress and improve diagnostics --- CHANGELOG.md | 36 +++++++++++++++++++++++++++++++++++- modules/cli | 2 +- modules/engine | 2 +- 3 files changed, 37 insertions(+), 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index ffbfd65..6a20727 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,6 +7,30 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 # Vix v2.8.4 +## Added + +### Live `vix build` progress + +`vix build` now provides a cleaner real-time build experience with structured progress instead of exposing raw compiler and Ninja output by default. + +- Build phases are now reported as semantic events for project preparation, configuration, compilation, linking, success, and failure. +- Compilation progress is displayed live with the current source file and progress counters when available. +- CMake and Ninja output is parsed in real time to detect compilation and linking phases. +- Native `vix.app` builds now use the same live build presentation. +- Parallel graph compilation reports progress safely across scheduler workers. +- Raw build output remains available through verbose and debug modes. + +Example: + +```text +Compiling my-app (dev) + βœ“ Project ready my-app + βœ“ Build configured + βœ“ Compilation finished + βœ“ Linked my-app + βœ“ Build completed my-app +``` + ## Fixed ### `vix run` stability and performance @@ -19,7 +43,17 @@ This release fixes important regressions introduced in v2.8.3. - Failed Direct script builds are cached and replayed without recompiling when the build fingerprint has not changed. - Negative-cache tracing now correctly reports matching failure metadata. -v2.8.4 restores fast and reliable standalone C++ execution while keeping explicit sanitizer support unchanged. +### Build diagnostics + +- Compilation failures now preserve the active build phase and display a clear `Compilation failed` status before the diagnostic. +- Linking failures now display a clear `Linking failed` status before Vix explains the missing symbol. +- Missing function implementations now produce clearer linker diagnostics with actionable hints. +- CMake and Ninja output is captured for diagnostics without flooding normal terminal output. +- Build graph progress events now include current and total operation counts. +- Native `vix.app`, `BuildGraphExecutor`, and CMake/Ninja build paths now share the same live build reporting infrastructure. +- `VIX_LOG_LEVEL=debug` and `VIX_LOG_LEVEL=trace` retain access to deeper technical build information. + +v2.8.4 restores fast and reliable standalone C++ execution while making `vix build` easier to follow and debug. # Vix v2.8.3, v2.8.2, v2.8.1 diff --git a/modules/cli b/modules/cli index 6a25c16..3e30dfe 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 6a25c166e7b6c396339334901b976fceb5298cc5 +Subproject commit 3e30dfec91264f4a5b15e3ecd8db3e46c1a9f95f diff --git a/modules/engine b/modules/engine index 65a6baf..3d5a704 160000 --- a/modules/engine +++ b/modules/engine @@ -1 +1 @@ -Subproject commit 65a6baf97155061cae31ffec3e9321de332311b2 +Subproject commit 3d5a704e7cf719aad687f46ebca4659ed42a6614 From 6f220290d7c3c8fc2fb6220aeac1d810bda3dba8 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Sat, 8 Aug 2026 22:56:21 +0300 Subject: [PATCH 03/19] perf: speed up warm vix run execution --- modules/cli | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/cli b/modules/cli index 3e30dfe..375465c 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 3e30dfec91264f4a5b15e3ecd8db3e46c1a9f95f +Subproject commit 375465c09d02fd99dd4a33d09f24ccab3ff55c1f From 49a11e48917d6219a8d4439c5aa8f81871567476 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Sun, 9 Aug 2026 11:59:18 +0300 Subject: [PATCH 04/19] fix: stabilize vix run script caching --- modules/cli | 2 +- modules/core | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/cli b/modules/cli index 375465c..26286d2 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 375465c09d02fd99dd4a33d09f24ccab3ff55c1f +Subproject commit 26286d2421b1ccc1af63fce86d7e90f8b0692947 diff --git a/modules/core b/modules/core index 663472d..a518b7a 160000 --- a/modules/core +++ b/modules/core @@ -1 +1 @@ -Subproject commit 663472d4ee29090e73d83765e81560a3eeb5da1a +Subproject commit a518b7ab4ea3ec1c3b40a592c548e251042370c8 From 3b9ca5e338435a4cad96e34928c88126011d77fe Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Sun, 9 Aug 2026 20:28:20 +0300 Subject: [PATCH 05/19] feat: improve v2.8.4 build workflow and diagnostics --- CHANGELOG.md | 199 ++++++++++++++++++++++++++++++++++++++++++++------- modules/cli | 2 +- 2 files changed, 173 insertions(+), 28 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 6a20727..a025655 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,51 +9,196 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ## Added -### Live `vix build` progress +### Unified `vix build` experience -`vix build` now provides a cleaner real-time build experience with structured progress instead of exposing raw compiler and Ninja output by default. +`vix build` now provides a cleaner and more consistent build experience focused on the information developers actually need while compiling their projects. -- Build phases are now reported as semantic events for project preparation, configuration, compilation, linking, success, and failure. -- Compilation progress is displayed live with the current source file and progress counters when available. -- CMake and Ninja output is parsed in real time to detect compilation and linking phases. -- Native `vix.app` builds now use the same live build presentation. +- Normal builds use a compact live progress interface instead of exposing raw CMake, Ninja, and compiler output. +- `vix build` and `vix build -v` now share the same visual presentation. +- `-v` enriches the normal build interface with useful build details without switching to a separate renderer. +- Build progress is reported in real time with operation counters when available. +- Native `vix.app`, BuildGraphExecutor, and CMake/Ninja build paths use the same build reporting infrastructure. - Parallel graph compilation reports progress safely across scheduler workers. -- Raw build output remains available through verbose and debug modes. +- Build phases are represented internally through semantic build events. +- Raw external build output remains available explicitly through `--cmake-verbose`. Example: ```text Compiling my-app (dev) - βœ“ Project ready my-app - βœ“ Build configured - βœ“ Compilation finished - βœ“ Linked my-app - βœ“ Build completed my-app + + build [============================] done + βœ” Finished dev [unoptimized + debuginfo] in 4.2s ``` +Verbose builds keep the same presentation while adding useful information: + +```text +Compiling my-app (dev) + +- launcher: ccache | linker: mold | jobs: 8 + build [============================] done + βœ” Finished dev [unoptimized + debuginfo] in 4.2s +``` + +### Build diagnostics + +`vix build` now exposes diagnostic functionality directly through documented CLI options instead of requiring users to inspect internal files or know hidden environment variables. + +Added: + +- `--debug` to display structured internal Vix build diagnostics. +- `--debug-log ` with: + - `cache` + - `graph` + - `configure` + - `process` + - `toolchain` + - `all` + +- `--log ` with: + - `build` + - `configure` + - `all` + +- `--graph-executor `. +- `--heartbeat` and `--no-heartbeat`. + +`--debug` remains separate from raw external output. + +Use: + +```bash +vix build --debug +``` + +for Vix diagnostics, and: + +```bash +vix build --cmake-verbose +``` + +for raw CMake, Ninja, and compiler output. + +Captured build logs can now be inspected directly: + +```bash +vix build --log build +vix build --log configure +vix build --log all +``` + +### Improved cross-platform build UX + +Cross-compilation options are now easier to discover and understand. + +- `--target native` explicitly selects the current host platform. +- `--targets` now reports detected targets and toolchain availability. +- Native, available, and unavailable targets are distinguished clearly. +- Cross-compilation builds show the selected target when it is relevant. +- Verbose cross builds can show the detected compiler and toolchain information. +- `--sysroot` documentation now makes its cross-toolchain role clearer. + +Example: + +```bash +vix build --target aarch64-linux-gnu +``` + +Target discovery: + +```bash +vix build --targets +``` + +### Explicit `vix run` options + +Several `vix run` behaviors that previously depended on environment variables are now exposed through documented CLI options. + +Added: + +- `--ui` / `--no-ui` +- `--env-hint` / `--no-env-hint` +- `--trace-cache` / `--no-trace-cache` +- `--compiler-fingerprint ` + +CLI options are now the primary user-facing interface while legacy environment-variable compatibility is preserved where necessary. + +## Improved + +### `vix run` warm-cache performance + +Repeated standalone C++ execution is significantly faster when the script and its dependencies have not changed. + +Vix now: + +- preserves Ninja dependency files for script builds; +- validates dependency modification times correctly across filesystem clock implementations; +- avoids unnecessary CMake and Ninja invocations on valid warm-cache runs; +- reuses previously built script executables when their dependency state remains valid; +- keeps cache fingerprints stable across repeated filesystem timestamp reads. + +On a tested warm path, `vix run main.cpp` can execute in roughly tens of milliseconds after the initial build. + +### Build help and discoverability + +`vix build --help` has been reorganized around documented CLI functionality. + +- Public environment-variable instructions have been removed from the help. +- Diagnostics are exposed through CLI options. +- Platform and cross-compilation options are documented more clearly. +- Error hints now point users to commands such as: + +```bash +vix build --debug +vix build --log build +vix build --log configure +``` + +instead of requiring `VIX_LOG_LEVEL=debug` or manual inspection of log files. + ## Fixed -### `vix run` stability and performance +### `vix run` stability and caching -This release fixes important regressions introduced in v2.8.3. +This release fixes important standalone C++ execution regressions. - Standalone C++ scripts no longer enable ASan and UBSan implicitly. -- Vix runtime scripts now use the reliable CMake fallback link path. -- Linker errors now preserve missing symbols and provide clearer diagnostics with source locations and actionable hints. -- Failed Direct script builds are cached and replayed without recompiling when the build fingerprint has not changed. -- Negative-cache tracing now correctly reports matching failure metadata. +- Vix runtime scripts can use the direct compilation path when the installed Vix libraries satisfy its requirements. +- Generated CMake script builds now use the correct unique CMake target name. +- Script dependency files are preserved so warm-cache validation can correctly detect unchanged dependencies. +- Filesystem modification timestamps are now encoded stably without assuming that `std::filesystem::file_time_type` uses the Unix epoch. +- Touching a source file without changing its contents no longer invalidates the Direct script cache unnecessarily. +- Failed Direct compilations no longer become reusable negative cache hits. +- A previous failed compilation is retried on the next invocation instead of suppressing the compiler. +- Successful builds continue to clean obsolete failure-cache metadata. +- Linker errors preserve missing symbols and provide clearer diagnostics with source locations and actionable hints. -### Build diagnostics +### Build diagnostics and progress + +- Compilation failures preserve the active build phase before displaying diagnostics. +- Linking failures clearly identify the linking stage before explaining missing symbols. +- Missing function implementations produce clearer linker diagnostics with actionable hints. +- CMake and Ninja output remains captured for diagnostics without flooding normal terminal output. +- Build graph progress events include current and total operation counts. +- Debug diagnostics no longer implicitly enable raw CMake/Ninja output. +- `vix build -v` no longer switches to a separate legacy build presentation. +- Build output remains visually consistent between normal, verbose, and debug modes. + +### Build configuration interface + +User-facing build configuration is no longer dependent on undocumented environment variables. + +Legacy mappings now have explicit CLI equivalents: + +- `VIX_BUILD_MANAGED_SDK` β†’ `--managed-sdk` +- `VIX_BUILD_HEARTBEAT` β†’ `--heartbeat` / `--no-heartbeat` +- `VIX_GRAPH_EXECUTOR` β†’ `--graph-executor` +- `VIX_LOG_LEVEL=debug` β†’ `--debug` -- Compilation failures now preserve the active build phase and display a clear `Compilation failed` status before the diagnostic. -- Linking failures now display a clear `Linking failed` status before Vix explains the missing symbol. -- Missing function implementations now produce clearer linker diagnostics with actionable hints. -- CMake and Ninja output is captured for diagnostics without flooding normal terminal output. -- Build graph progress events now include current and total operation counts. -- Native `vix.app`, `BuildGraphExecutor`, and CMake/Ninja build paths now share the same live build reporting infrastructure. -- `VIX_LOG_LEVEL=debug` and `VIX_LOG_LEVEL=trace` retain access to deeper technical build information. +Legacy environment variables may remain compatible for existing scripts, but the CLI is now the documented interface. -v2.8.4 restores fast and reliable standalone C++ execution while making `vix build` easier to follow and debug. +v2.8.4 improves the everyday C++ development loop in Vix: faster warm `vix run`, a stable and compact `vix build` interface, clearer diagnostics, and easier-to-discover build and cross-compilation controls. # Vix v2.8.3, v2.8.2, v2.8.1 diff --git a/modules/cli b/modules/cli index 26286d2..5319820 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 26286d2421b1ccc1af63fce86d7e90f8b0692947 +Subproject commit 53198202dd4b027e88519d41a7b6ebe41f2cb7e6 From ea86292f7577561a3e0e410a10338b168bb663b0 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Mon, 10 Aug 2026 11:25:34 +0300 Subject: [PATCH 06/19] feat: finalize v2.8.4 runtime and CLI improvements --- CHANGELOG.md | 319 ++++++++++++++++++++++++++++++++++++++------------- modules/cli | 2 +- modules/core | 2 +- 3 files changed, 243 insertions(+), 80 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index a025655..88475bf 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -13,14 +13,14 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 `vix build` now provides a cleaner and more consistent build experience focused on the information developers actually need while compiling their projects. -- Normal builds use a compact live progress interface instead of exposing raw CMake, Ninja, and compiler output. -- `vix build` and `vix build -v` now share the same visual presentation. -- `-v` enriches the normal build interface with useful build details without switching to a separate renderer. -- Build progress is reported in real time with operation counters when available. -- Native `vix.app`, BuildGraphExecutor, and CMake/Ninja build paths use the same build reporting infrastructure. -- Parallel graph compilation reports progress safely across scheduler workers. -- Build phases are represented internally through semantic build events. -- Raw external build output remains available explicitly through `--cmake-verbose`. +* Normal builds use a compact live progress interface instead of exposing raw CMake, Ninja, and compiler output. +* `vix build` and `vix build -v` now share the same visual presentation. +* `-v` enriches the normal build interface with useful build details without switching to a separate renderer. +* Build progress is reported in real time with operation counters when available. +* Native `vix.app`, BuildGraphExecutor, and CMake/Ninja build paths use the same build reporting infrastructure. +* Parallel graph compilation reports progress safely across scheduler workers. +* Build phases are represented internally through semantic build events. +* Raw external build output remains available explicitly through `--cmake-verbose`. Example: @@ -43,28 +43,28 @@ Compiling my-app (dev) ### Build diagnostics -`vix build` now exposes diagnostic functionality directly through documented CLI options instead of requiring users to inspect internal files or know hidden environment variables. +`vix build` now exposes diagnostic functionality directly through documented CLI options instead of requiring users to inspect internal files or rely on hidden environment variables. Added: -- `--debug` to display structured internal Vix build diagnostics. -- `--debug-log ` with: - - `cache` - - `graph` - - `configure` - - `process` - - `toolchain` - - `all` +* `--debug` for structured internal Vix build diagnostics. +* `--debug-log ` for targeted internal diagnostics. +* `--log` for inspecting the latest relevant build log. +* `--log ` for displaying an explicit log file. +* `--log ` for discovering and displaying the relevant log from a build directory. +* `--graph-executor `. +* `--heartbeat` and `--no-heartbeat`. -- `--log ` with: - - `build` - - `configure` - - `all` +Available `--debug-log` scopes include: -- `--graph-executor `. -- `--heartbeat` and `--no-heartbeat`. +* `cache` +* `graph` +* `configure` +* `process` +* `toolchain` +* `all` -`--debug` remains separate from raw external output. +`--debug` remains separate from raw external build output. Use: @@ -80,24 +80,28 @@ vix build --cmake-verbose for raw CMake, Ninja, and compiler output. -Captured build logs can now be inspected directly: +Captured build logs can be inspected directly: ```bash -vix build --log build -vix build --log configure -vix build --log all +vix build --log +vix build --log build-ninja/build.log +vix build --log build-ninja/ ``` +When a directory is provided, Vix prefers its canonical `build.log` when available before falling back to log discovery. + +Legacy `build`, `configure`, and `all` log selectors remain available where required for compatibility. + ### Improved cross-platform build UX Cross-compilation options are now easier to discover and understand. -- `--target native` explicitly selects the current host platform. -- `--targets` now reports detected targets and toolchain availability. -- Native, available, and unavailable targets are distinguished clearly. -- Cross-compilation builds show the selected target when it is relevant. -- Verbose cross builds can show the detected compiler and toolchain information. -- `--sysroot` documentation now makes its cross-toolchain role clearer. +* `--target native` explicitly selects the current platform. +* `--targets` reports the native target together with detected cross-toolchains. +* Target discovery is based on the toolchains actually available on the system instead of a fixed built-in list. +* Cross-compilation builds can display the selected target when relevant. +* Verbose builds can expose detected compiler and toolchain information. +* `--sysroot` is exposed as a generic target-toolchain option. Example: @@ -117,73 +121,215 @@ Several `vix run` behaviors that previously depended on environment variables ar Added: -- `--ui` / `--no-ui` -- `--env-hint` / `--no-env-hint` -- `--trace-cache` / `--no-trace-cache` -- `--compiler-fingerprint ` +* `--ui` / `--no-ui` +* `--env-hint` / `--no-env-hint` +* `--trace-cache` / `--no-trace-cache` +* `--compiler-fingerprint ` + +CLI options are now the primary user-facing interface while compatibility with existing workflows is preserved where necessary. + +### CLI contract coverage + +The CLI now has broader regression coverage for both `vix run` and `vix build`. + +The test suite tracks: + +* all public `vix run` options; +* all public `vix build` options; +* source, project, binary, manifest, and adapter execution paths; +* direct and CMake-backed script execution; +* local and transitive header dependencies; +* compiled and transitively compiled dependencies; +* build targets and passthrough CMake arguments; +* build output modes; +* cache behavior; +* graph executor behavior; +* native toolchain discovery; +* SDK profile composition. + +Public CLI options are checked against a contract matrix so newly exposed options cannot silently remain unclassified by the regression suite. -CLI options are now the primary user-facing interface while legacy environment-variable compatibility is preserved where necessary. +Capability coverage is tracked separately from option coverage so an option being parseable is not considered proof that every execution path using it works. ## Improved -### `vix run` warm-cache performance +### `vix run` performance + +`vix run` now provides a much faster development loop while preserving correct dependency and linkage behavior. + +For standalone C++ programs, Vix keeps a lightweight direct compilation path: + +* plain C++ sources compile without requiring CMake; +* valid warm-cache executions avoid recompilation; +* cached standalone executables can start in tens of milliseconds; +* dependency fingerprints detect meaningful source and header changes; +* touching a file without changing its contents does not unnecessarily invalidate the direct cache. + +Example observed warm standalone runs: + +```text +$ time vix run hello.cpp +Hello, world + +real 0m0.064s +``` + +This is significantly faster than recompiling the same source directly with the compiler on every invocation. -Repeated standalone C++ execution is significantly faster when the script and its dependencies have not changed. +Programs that require compiled Vix runtime functionality now use the CMake-backed path so Vix can preserve the complete package and transitive linkage requirements instead of relying on an incomplete heuristic library list. + +CMake-backed runs also reuse their existing generated build tree and compiled artifacts across repeated executions, substantially reducing subsequent startup cost. + +Example observed Vix runtime execution: + +```text +cold run: ~3.8s +warm run: ~0.7s +``` + +The application runtime itself can still start in approximately milliseconds once the executable is launched. + +### Dependency-aware script caching + +Direct script caching now tracks the local headers actually used by a translation unit. Vix now: -- preserves Ninja dependency files for script builds; -- validates dependency modification times correctly across filesystem clock implementations; -- avoids unnecessary CMake and Ninja invocations on valid warm-cache runs; -- reuses previously built script executables when their dependency state remains valid; -- keeps cache fingerprints stable across repeated filesystem timestamp reads. +* asks the compiler for real dependency information using dependency generation; +* fingerprints resolved local headers by content; +* follows transitive local includes; +* invalidates the cache when header contents actually change; +* preserves a cache hit when a header is only touched without changing its contents. + +For example: + +```text +main.cpp + -> value.hpp + -> nested.hpp +``` + +Changing `nested.hpp` now correctly invalidates the cached executable. + +### Correct compiled dependency handling + +`vix run` now distinguishes between code that can safely use the direct compilation path and code that requires complete build-system usage requirements. + +This prevents cases where: + +* a header was found successfully; +* compilation succeeded; +* but the implementation library was missing at link time. + +Compiled dependencies and Vix runtime code can now use the CMake-backed path when full target, library, and transitive dependency information is required. -On a tested warm path, `vix run main.cpp` can execute in roughly tens of milliseconds after the initial build. +Transitive compiled dependency graphs such as: + +```text +application + -> library A + -> library B +``` + +are rebuilt correctly when an underlying library changes. + +### Build graph execution reliability + +Forced BuildGraphExecutor builds now honor the requested backend instead of being bypassed by unrelated cache or artifact-restoration shortcuts. + +This ensures that: + +```bash +vix build --graph-executor on +``` + +actually exercises the graph executor when the project is eligible. + +Source changes and compilation failures are also propagated correctly through this path. ### Build help and discoverability `vix build --help` has been reorganized around documented CLI functionality. -- Public environment-variable instructions have been removed from the help. -- Diagnostics are exposed through CLI options. -- Platform and cross-compilation options are documented more clearly. -- Error hints now point users to commands such as: +* Public environment-variable instructions have been removed from the help. +* Diagnostics are exposed through CLI options. +* Platform and cross-compilation options are documented more clearly. +* User-facing log inspection no longer requires knowledge of internal log layouts. +* Error hints point users toward documented commands such as: ```bash vix build --debug -vix build --log build -vix build --log configure +vix build --log ``` -instead of requiring `VIX_LOG_LEVEL=debug` or manual inspection of log files. +instead of requiring `VIX_LOG_LEVEL=debug` or manual inspection of internal files. ## Fixed ### `vix run` stability and caching -This release fixes important standalone C++ execution regressions. +This release fixes several standalone and CMake-backed script execution regressions. + +* Standalone C++ scripts no longer enable ASan and UBSan implicitly. +* Plain standalone C++ continues to use the fast direct compilation path. +* Programs requiring compiled Vix runtime functionality no longer rely on an incomplete heuristic list of libraries. +* Vix runtime programs use the exported package/build information needed for correct linkage. +* Missing compiled implementations are no longer caused by selecting an unsafe direct-link path. +* Generated CMake script builds use the correct unique CMake target name. +* CMake-backed script builds no longer skip required dependency work solely because the final executable depfile appears unchanged. +* Ninja remains responsible for determining which parts of a compiled dependency graph need rebuilding. +* Direct-script dependency files are preserved for cache validation. +* Local and transitive header changes correctly invalidate direct-script cache entries. +* Filesystem modification timestamps are encoded stably without assuming that `std::filesystem::file_time_type` uses the Unix epoch. +* Touching a source or tracked header without changing its contents does not unnecessarily invalidate the content-based direct cache. +* Failed direct compilations no longer become reusable negative cache hits. +* A previous failed compilation is retried on the next invocation instead of suppressing the compiler. +* Successful builds clean obsolete failure-cache metadata. +* Linker errors preserve missing symbols and provide clearer source-aware diagnostics and actionable hints. + +### Linker diagnostics + +Link failures now produce structured diagnostics without introducing a secondary compilation pipeline. -- Standalone C++ scripts no longer enable ASan and UBSan implicitly. -- Vix runtime scripts can use the direct compilation path when the installed Vix libraries satisfy its requirements. -- Generated CMake script builds now use the correct unique CMake target name. -- Script dependency files are preserved so warm-cache validation can correctly detect unchanged dependencies. -- Filesystem modification timestamps are now encoded stably without assuming that `std::filesystem::file_time_type` uses the Unix epoch. -- Touching a source file without changing its contents no longer invalidates the Direct script cache unnecessarily. -- Failed Direct compilations no longer become reusable negative cache hits. -- A previous failed compilation is retried on the next invocation instead of suppressing the compiler. -- Successful builds continue to clean obsolete failure-cache metadata. -- Linker errors preserve missing symbols and provide clearer diagnostics with source locations and actionable hints. +For missing function implementations, Vix can report: + +```text +link error: function has no implementation + +The function `example()` is used by the program, +but the linker could not find its function body. +``` + +The diagnostic is produced from the linker output already captured by Vix rather than invoking another compiler or build pass solely for error analysis. ### Build diagnostics and progress -- Compilation failures preserve the active build phase before displaying diagnostics. -- Linking failures clearly identify the linking stage before explaining missing symbols. -- Missing function implementations produce clearer linker diagnostics with actionable hints. -- CMake and Ninja output remains captured for diagnostics without flooding normal terminal output. -- Build graph progress events include current and total operation counts. -- Debug diagnostics no longer implicitly enable raw CMake/Ninja output. -- `vix build -v` no longer switches to a separate legacy build presentation. -- Build output remains visually consistent between normal, verbose, and debug modes. +* Compilation failures preserve the active build phase before displaying diagnostics. +* Linking failures clearly identify the linking stage before explaining missing symbols. +* Missing function implementations produce clearer linker diagnostics with actionable hints. +* CMake and Ninja output remains captured for diagnostics without flooding normal terminal output. +* Build graph progress events include current and total operation counts. +* Debug diagnostics no longer implicitly enable raw CMake/Ninja output. +* `vix build -v` no longer switches to a separate legacy build presentation. +* Build output remains visually consistent between normal, verbose, and debug modes. + +### Build log selection + +Directory-based build log inspection is now deterministic. + +When running: + +```bash +vix build --log build-ninja/ +``` + +Vix prefers: + +```text +build-ninja/build.log +``` + +when it exists instead of accidentally selecting another recently modified log such as `configure.log`. ### Build configuration interface @@ -191,14 +337,31 @@ User-facing build configuration is no longer dependent on undocumented environme Legacy mappings now have explicit CLI equivalents: -- `VIX_BUILD_MANAGED_SDK` β†’ `--managed-sdk` -- `VIX_BUILD_HEARTBEAT` β†’ `--heartbeat` / `--no-heartbeat` -- `VIX_GRAPH_EXECUTOR` β†’ `--graph-executor` -- `VIX_LOG_LEVEL=debug` β†’ `--debug` +* `VIX_BUILD_MANAGED_SDK` β†’ `--managed-sdk` +* `VIX_BUILD_HEARTBEAT` β†’ `--heartbeat` / `--no-heartbeat` +* `VIX_GRAPH_EXECUTOR` β†’ `--graph-executor` +* `VIX_LOG_LEVEL=debug` β†’ `--debug` Legacy environment variables may remain compatible for existing scripts, but the CLI is now the documented interface. -v2.8.4 improves the everyday C++ development loop in Vix: faster warm `vix run`, a stable and compact `vix build` interface, clearer diagnostics, and easier-to-discover build and cross-compilation controls. +## Summary + +Vix v2.8.4 strengthens both correctness and performance across the everyday C++ development loop. + +It brings: + +* fast direct execution for standalone C++; +* correct CMake-backed linkage for compiled Vix runtime code; +* content-aware local and transitive header caching; +* safer compiled and transitive dependency rebuilding; +* clearer linker and build diagnostics; +* a compact and consistent `vix build` experience; +* dynamic target and toolchain discovery; +* deterministic build-log inspection; +* stronger regression contracts for the public `vix run` and `vix build` interfaces. + +The result is a faster development loop without trading away dependency correctness or linker reliability. + # Vix v2.8.3, v2.8.2, v2.8.1 diff --git a/modules/cli b/modules/cli index 5319820..9fc92b6 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 53198202dd4b027e88519d41a7b6ebe41f2cb7e6 +Subproject commit 9fc92b6b0397239a21df4fa004b33aa0eeeae5b1 diff --git a/modules/core b/modules/core index a518b7a..3d56ef4 160000 --- a/modules/core +++ b/modules/core @@ -1 +1 @@ -Subproject commit a518b7ab4ea3ec1c3b40a592c548e251042370c8 +Subproject commit 3d56ef4fe7b98644032642bbcb23d113d06c35ba From 70ca286cfcc783a80fd74797e339bdfa3a5a5eb9 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Tue, 11 Aug 2026 14:28:56 +0300 Subject: [PATCH 07/19] fix: improve dev lifecycle and server startup --- modules/cli | 2 +- modules/core | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/cli b/modules/cli index 9fc92b6..667690e 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 9fc92b6b0397239a21df4fa004b33aa0eeeae5b1 +Subproject commit 667690edbde83632ebd7f10cdd84578a80552da7 diff --git a/modules/core b/modules/core index 3d56ef4..432ae91 160000 --- a/modules/core +++ b/modules/core @@ -1 +1 @@ -Subproject commit 3d56ef4fe7b98644032642bbcb23d113d06c35ba +Subproject commit 432ae91912b4968372c499dd7bbd877eaf24560a From 59edadb0df24069f340ab3ebe0431bd0e230e1c1 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Tue, 11 Aug 2026 15:08:44 +0300 Subject: [PATCH 08/19] fix: keep fast builds configuration-stable --- modules/cli | 2 +- modules/engine | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/cli b/modules/cli index 667690e..5035e89 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 667690edbde83632ebd7f10cdd84578a80552da7 +Subproject commit 5035e8918468e35a6b397f1d2a53ff35fe67d2fb diff --git a/modules/engine b/modules/engine index 3d5a704..781a003 160000 --- a/modules/engine +++ b/modules/engine @@ -1 +1 @@ -Subproject commit 3d5a704e7cf719aad687f46ebca4659ed42a6614 +Subproject commit 781a00391d00d44f8af314b6af7f5dda9652068a From 6eeb14b1b68e79c957621b1a19642c2621e091b6 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Tue, 11 Aug 2026 21:42:22 +0300 Subject: [PATCH 09/19] fix: stabilize fast builds and dev recovery --- modules/cli | 2 +- modules/engine | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/cli b/modules/cli index 5035e89..37744e7 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 5035e8918468e35a6b397f1d2a53ff35fe67d2fb +Subproject commit 37744e75b6f655707a68c6054bc0502737f44170 diff --git a/modules/engine b/modules/engine index 781a003..aaad94e 160000 --- a/modules/engine +++ b/modules/engine @@ -1 +1 @@ -Subproject commit 781a00391d00d44f8af314b6af7f5dda9652068a +Subproject commit aaad94e52562ac7bd905892c87926530afd75014 From c163ad81d995b814df2300d7f08937a391058ace Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Wed, 12 Aug 2026 09:17:48 +0300 Subject: [PATCH 10/19] fix: stabilize CLI umbrella and dev contracts --- modules/cli | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/cli b/modules/cli index 37744e7..7f527d5 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 37744e75b6f655707a68c6054bc0502737f44170 +Subproject commit 7f527d502be0c45bad76d1d91992197fda566fcd From 99cfb6f09c432f4e4aec6cd526c4150905ddd7af Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Wed, 12 Aug 2026 12:01:19 +0300 Subject: [PATCH 11/19] perf: reduce compile overhead and finalize v2.8.4 changes --- CHANGELOG.md | 374 ++++++++----------------------------------------- CMakeLists.txt | 15 ++ modules/core | 2 +- modules/json | 2 +- modules/utils | 2 +- 5 files changed, 75 insertions(+), 320 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 88475bf..ab91d69 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,360 +7,100 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 # Vix v2.8.4 +Vix v2.8.4 improves the everyday C++ development loop with faster builds, lighter public headers, safer caching, better diagnostics, and more consistent `build`, `run`, and `dev` behavior. + ## Added ### Unified `vix build` experience -`vix build` now provides a cleaner and more consistent build experience focused on the information developers actually need while compiling their projects. - -* Normal builds use a compact live progress interface instead of exposing raw CMake, Ninja, and compiler output. -* `vix build` and `vix build -v` now share the same visual presentation. -* `-v` enriches the normal build interface with useful build details without switching to a separate renderer. -* Build progress is reported in real time with operation counters when available. -* Native `vix.app`, BuildGraphExecutor, and CMake/Ninja build paths use the same build reporting infrastructure. -* Parallel graph compilation reports progress safely across scheduler workers. -* Build phases are represented internally through semantic build events. -* Raw external build output remains available explicitly through `--cmake-verbose`. - -Example: - -```text -Compiling my-app (dev) - - build [============================] done - βœ” Finished dev [unoptimized + debuginfo] in 4.2s -``` - -Verbose builds keep the same presentation while adding useful information: - -```text -Compiling my-app (dev) - -- launcher: ccache | linker: mold | jobs: 8 - build [============================] done - βœ” Finished dev [unoptimized + debuginfo] in 4.2s -``` - -### Build diagnostics +`vix build` now uses a compact and consistent live build interface across native, graph-executor, and CMake/Ninja builds. -`vix build` now exposes diagnostic functionality directly through documented CLI options instead of requiring users to inspect internal files or rely on hidden environment variables. - -Added: +* `vix build` and `vix build -v` share the same presentation. +* `-v` adds useful toolchain and build information. +* `--debug` exposes structured Vix diagnostics. +* `--cmake-verbose` remains available for raw CMake/Ninja/compiler output. +* Build logs can be inspected directly with `vix build --log`. -* `--debug` for structured internal Vix build diagnostics. -* `--debug-log ` for targeted internal diagnostics. -* `--log` for inspecting the latest relevant build log. -* `--log ` for displaying an explicit log file. -* `--log ` for discovering and displaying the relevant log from a build directory. -* `--graph-executor `. -* `--heartbeat` and `--no-heartbeat`. +### Better cross-compilation support -Available `--debug-log` scopes include: - -* `cache` -* `graph` -* `configure` -* `process` -* `toolchain` -* `all` - -`--debug` remains separate from raw external build output. - -Use: - -```bash -vix build --debug -``` - -for Vix diagnostics, and: - -```bash -vix build --cmake-verbose -``` - -for raw CMake, Ninja, and compiler output. - -Captured build logs can be inspected directly: - -```bash -vix build --log -vix build --log build-ninja/build.log -vix build --log build-ninja/ -``` +* `--target native` explicitly selects the host platform. +* `--targets` discovers available native and cross toolchains. +* `--sysroot` is available for target toolchains. -When a directory is provided, Vix prefers its canonical `build.log` when available before falling back to log discovery. +### Explicit `vix run` controls -Legacy `build`, `configure`, and `all` log selectors remain available where required for compatibility. - -### Improved cross-platform build UX - -Cross-compilation options are now easier to discover and understand. - -* `--target native` explicitly selects the current platform. -* `--targets` reports the native target together with detected cross-toolchains. -* Target discovery is based on the toolchains actually available on the system instead of a fixed built-in list. -* Cross-compilation builds can display the selected target when relevant. -* Verbose builds can expose detected compiler and toolchain information. -* `--sysroot` is exposed as a generic target-toolchain option. - -Example: - -```bash -vix build --target aarch64-linux-gnu -``` - -Target discovery: - -```bash -vix build --targets -``` - -### Explicit `vix run` options - -Several `vix run` behaviors that previously depended on environment variables are now exposed through documented CLI options. - -Added: +Added documented CLI options for runtime behavior previously controlled primarily through internal or environment-based configuration: * `--ui` / `--no-ui` * `--env-hint` / `--no-env-hint` * `--trace-cache` / `--no-trace-cache` * `--compiler-fingerprint ` -CLI options are now the primary user-facing interface while compatibility with existing workflows is preserved where necessary. - -### CLI contract coverage - -The CLI now has broader regression coverage for both `vix run` and `vix build`. - -The test suite tracks: - -* all public `vix run` options; -* all public `vix build` options; -* source, project, binary, manifest, and adapter execution paths; -* direct and CMake-backed script execution; -* local and transitive header dependencies; -* compiled and transitively compiled dependencies; -* build targets and passthrough CMake arguments; -* build output modes; -* cache behavior; -* graph executor behavior; -* native toolchain discovery; -* SDK profile composition. - -Public CLI options are checked against a contract matrix so newly exposed options cannot silently remain unclassified by the regression suite. - -Capability coverage is tracked separately from option coverage so an option being parseable is not considered proof that every execution path using it works. - ## Improved -### `vix run` performance +### Faster C++ compilation -`vix run` now provides a much faster development loop while preserving correct dependency and linkage behavior. +Vix public headers have been significantly reduced and decoupled from heavy implementation details. -For standalone C++ programs, Vix keeps a lightweight direct compilation path: +* `App` no longer exposes Router, HTTPServer, RequestHandler, runtime executor, or Asio internals unnecessarily. +* `core.hpp` no longer pulls advanced HTTP/router implementation headers into every `` consumer. +* JSON-heavy `Config` and response implementation has been moved out of public headers where possible. +* Logger internals no longer expose spdlog throughout user translation units. +* Public APIs such as GET routes, POST JSON, middleware, Config, and logging remain compatible. -* plain C++ sources compile without requiring CMake; -* valid warm-cache executions avoid recompilation; -* cached standalone executables can start in tens of milliseconds; -* dependency fingerprints detect meaningful source and header changes; -* touching a file without changing its contents does not unnecessarily invalidate the direct cache. +This substantially reduces compiler CPU time and memory usage for applications using ``. -Example observed warm standalone runs: +### Faster `vix run` -```text -$ time vix run hello.cpp -Hello, world - -real 0m0.064s -``` - -This is significantly faster than recompiling the same source directly with the compiler on every invocation. +Standalone C++ programs keep the lightweight direct compilation path, while programs requiring compiled Vix runtime functionality use the correct CMake-backed path. -Programs that require compiled Vix runtime functionality now use the CMake-backed path so Vix can preserve the complete package and transitive linkage requirements instead of relying on an incomplete heuristic library list. +Warm executions reuse validated build state and compiled artifacts without unnecessary recompilation. -CMake-backed runs also reuse their existing generated build tree and compiled artifacts across repeated executions, substantially reducing subsequent startup cost. +### Dependency-aware caching -Example observed Vix runtime execution: - -```text -cold run: ~3.8s -warm run: ~0.7s -``` +Script caching now correctly tracks source files and local/transitive headers by content. -The application runtime itself can still start in approximately milliseconds once the executable is launched. +* Header changes invalidate affected builds. +* Touching an unchanged file does not unnecessarily rebuild. +* Failed compilations are not reused as cache hits. +* Compiled dependency graphs are rebuilt only when required. -### Dependency-aware script caching +### Better `vix dev` -Direct script caching now tracks the local headers actually used by a translation unit. +`vix dev` now handles source and transitive-header changes more reliably. -Vix now: - -* asks the compiler for real dependency information using dependency generation; -* fingerprints resolved local headers by content; -* follows transitive local includes; -* invalidates the cache when header contents actually change; -* preserves a cache hit when a header is only touched without changing its contents. - -For example: - -```text -main.cpp - -> value.hpp - -> nested.hpp -``` - -Changing `nested.hpp` now correctly invalidates the cached executable. - -### Correct compiled dependency handling - -`vix run` now distinguishes between code that can safely use the direct compilation path and code that requires complete build-system usage requirements. - -This prevents cases where: - -* a header was found successfully; -* compilation succeeded; -* but the implementation library was missing at link time. - -Compiled dependencies and Vix runtime code can now use the CMake-backed path when full target, library, and transitive dependency information is required. - -Transitive compiled dependency graphs such as: - -```text -application - -> library A - -> library B -``` - -are rebuilt correctly when an underlying library changes. - -### Build graph execution reliability - -Forced BuildGraphExecutor builds now honor the requested backend instead of being bypassed by unrelated cache or artifact-restoration shortcuts. - -This ensures that: - -```bash -vix build --graph-executor on -``` - -actually exercises the graph executor when the project is eligible. - -Source changes and compilation failures are also propagated correctly through this path. - -### Build help and discoverability - -`vix build --help` has been reorganized around documented CLI functionality. - -* Public environment-variable instructions have been removed from the help. -* Diagnostics are exposed through CLI options. -* Platform and cross-compilation options are documented more clearly. -* User-facing log inspection no longer requires knowledge of internal log layouts. -* Error hints point users toward documented commands such as: - -```bash -vix build --debug -vix build --log -``` - -instead of requiring `VIX_LOG_LEVEL=debug` or manual inspection of internal files. +* Dependency changes trigger a single rebuild/restart. +* Content changes are detected even on filesystems with coarse timestamps. +* Dependency sets are refreshed after successful rebuilds. +* Shutdown and interruption handling is more predictable. ## Fixed -### `vix run` stability and caching - -This release fixes several standalone and CMake-backed script execution regressions. - -* Standalone C++ scripts no longer enable ASan and UBSan implicitly. -* Plain standalone C++ continues to use the fast direct compilation path. -* Programs requiring compiled Vix runtime functionality no longer rely on an incomplete heuristic list of libraries. -* Vix runtime programs use the exported package/build information needed for correct linkage. -* Missing compiled implementations are no longer caused by selecting an unsafe direct-link path. -* Generated CMake script builds use the correct unique CMake target name. -* CMake-backed script builds no longer skip required dependency work solely because the final executable depfile appears unchanged. -* Ninja remains responsible for determining which parts of a compiled dependency graph need rebuilding. -* Direct-script dependency files are preserved for cache validation. -* Local and transitive header changes correctly invalidate direct-script cache entries. -* Filesystem modification timestamps are encoded stably without assuming that `std::filesystem::file_time_type` uses the Unix epoch. -* Touching a source or tracked header without changing its contents does not unnecessarily invalidate the content-based direct cache. -* Failed direct compilations no longer become reusable negative cache hits. -* A previous failed compilation is retried on the next invocation instead of suppressing the compiler. -* Successful builds clean obsolete failure-cache metadata. -* Linker errors preserve missing symbols and provide clearer source-aware diagnostics and actionable hints. - -### Linker diagnostics - -Link failures now produce structured diagnostics without introducing a secondary compilation pipeline. - -For missing function implementations, Vix can report: - -```text -link error: function has no implementation - -The function `example()` is used by the program, -but the linker could not find its function body. -``` - -The diagnostic is produced from the linker output already captured by Vix rather than invoking another compiler or build pass solely for error analysis. - -### Build diagnostics and progress - -* Compilation failures preserve the active build phase before displaying diagnostics. -* Linking failures clearly identify the linking stage before explaining missing symbols. -* Missing function implementations produce clearer linker diagnostics with actionable hints. -* CMake and Ninja output remains captured for diagnostics without flooding normal terminal output. -* Build graph progress events include current and total operation counts. -* Debug diagnostics no longer implicitly enable raw CMake/Ninja output. -* `vix build -v` no longer switches to a separate legacy build presentation. -* Build output remains visually consistent between normal, verbose, and debug modes. - -### Build log selection - -Directory-based build log inspection is now deterministic. - -When running: - -```bash -vix build --log build-ninja/ -``` - -Vix prefers: - -```text -build-ninja/build.log -``` - -when it exists instead of accidentally selecting another recently modified log such as `configure.log`. - -### Build configuration interface - -User-facing build configuration is no longer dependent on undocumented environment variables. - -Legacy mappings now have explicit CLI equivalents: - -* `VIX_BUILD_MANAGED_SDK` β†’ `--managed-sdk` -* `VIX_BUILD_HEARTBEAT` β†’ `--heartbeat` / `--no-heartbeat` -* `VIX_GRAPH_EXECUTOR` β†’ `--graph-executor` -* `VIX_LOG_LEVEL=debug` β†’ `--debug` - -Legacy environment variables may remain compatible for existing scripts, but the CLI is now the documented interface. +* Fixed incomplete linkage when running code that depends on compiled Vix libraries. +* Fixed transitive compiled dependency rebuilding. +* Fixed stale script/build cache decisions. +* Fixed generated CMake target handling for script builds. +* Fixed `--fast` builds incorrectly missing reusable configuration state. +* Fixed graph-executor builds being bypassed by unrelated cache paths. +* Fixed linker diagnostics for missing implementations and libraries. +* Fixed build-log selection when a build directory is provided. +* Fixed server startup reporting so `READY` is emitted only after successful startup. +* Fixed port configuration and bind-error propagation. +* Fixed local build-tree CMake package exports so Vix can be consumed directly from the current build without falling back to an installed runtime. ## Summary -Vix v2.8.4 strengthens both correctness and performance across the everyday C++ development loop. - -It brings: +Vix v2.8.4 makes the development loop faster and more predictable: -* fast direct execution for standalone C++; -* correct CMake-backed linkage for compiled Vix runtime code; -* content-aware local and transitive header caching; -* safer compiled and transitive dependency rebuilding; -* clearer linker and build diagnostics; -* a compact and consistent `vix build` experience; -* dynamic target and toolchain discovery; -* deterministic build-log inspection; -* stronger regression contracts for the public `vix run` and `vix build` interfaces. +* lighter C++ compilation; +* fast warm `vix run`; +* safer dependency-aware caching; +* more reliable `vix dev`; +* correct compiled-library linkage; +* clearer build and linker diagnostics; +* consistent build output; +* improved local and cross-platform tooling. -The result is a faster development loop without trading away dependency correctness or linker reliability. # Vix v2.8.3, v2.8.2, v2.8.1 diff --git a/CMakeLists.txt b/CMakeLists.txt index 447a3a8..1ebe21b 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -2134,6 +2134,12 @@ if (VIX_ENABLE_INSTALL) install(TARGETS vix EXPORT VixTargets) + # Public build-tree exports retain this interface dependency. Export it as + # well so `VixTargets.cmake` is valid both before and after installation. + if (TARGET vix_warnings) + install(TARGETS vix_warnings EXPORT VixTargets) + endif() + if (TARGET vix_thirdparty_asio) install(TARGETS vix_thirdparty_asio EXPORT VixTargets) endif() @@ -2298,6 +2304,15 @@ if (VIX_ENABLE_INSTALL) NAMESPACE vix:: DESTINATION "${VIX_INSTALL_CMAKEDIR}") + # Make the configured build tree consumable by integration tests and local + # tools before installation. VixConfig.cmake is generated in the build + # directory too; without this companion export it points at a target file + # that exists only after `cmake --install`, causing consumers to silently + # fall back to an unrelated system Vix package. + export(EXPORT VixTargets + FILE "${CMAKE_CURRENT_BINARY_DIR}/VixTargets.cmake" + NAMESPACE vix::) + install(FILES "${CMAKE_CURRENT_BINARY_DIR}/VixConfig.cmake" "${CMAKE_CURRENT_BINARY_DIR}/VixConfigVersion.cmake" diff --git a/modules/core b/modules/core index 432ae91..e69428c 160000 --- a/modules/core +++ b/modules/core @@ -1 +1 @@ -Subproject commit 432ae91912b4968372c499dd7bbd877eaf24560a +Subproject commit e69428cec5413d527346e4f55ee6fccaa171c82a diff --git a/modules/json b/modules/json index 8b09521..511d8f9 160000 --- a/modules/json +++ b/modules/json @@ -1 +1 @@ -Subproject commit 8b095215a8ab357acb42284e04f8c2ff39bbaba4 +Subproject commit 511d8f905db4b963ecff8ce45b53857f0ee39dce diff --git a/modules/utils b/modules/utils index 36df9cb..1845e1f 160000 --- a/modules/utils +++ b/modules/utils @@ -1 +1 @@ -Subproject commit 36df9cb03170d7e025249100f397cf68db47e53d +Subproject commit 1845e1f93509b8dbecfdac100266c37e67b48655 From 15d7c9eb4e0a521b5b4575e8bec5a83d1b22ea5e Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Wed, 12 Aug 2026 16:55:14 +0300 Subject: [PATCH 12/19] perf: stabilize builds and add public core benchmarks --- .github/workflows/core-benchmarks.yml | 266 ++++++++++++++++++++++++++ modules/cli | 2 +- modules/core | 2 +- modules/engine | 2 +- modules/websocket | 2 +- 5 files changed, 270 insertions(+), 4 deletions(-) create mode 100644 .github/workflows/core-benchmarks.yml diff --git a/.github/workflows/core-benchmarks.yml b/.github/workflows/core-benchmarks.yml new file mode 100644 index 0000000..c1de3c9 --- /dev/null +++ b/.github/workflows/core-benchmarks.yml @@ -0,0 +1,266 @@ +name: Core benchmarks + +on: + pull_request: + branches: + - main + - dev + - release/** + paths: + - ".github/workflows/core-benchmarks.yml" + - "CMakeLists.txt" + - "cmake/**" + - "modules/**" + - ".gitmodules" + workflow_dispatch: + inputs: + base_ref: + description: "Baseline Git ref (default: repository default branch)" + required: false + type: string + candidate_ref: + description: "Candidate Git ref (default: workflow commit)" + required: false + type: string + +permissions: + contents: read + +concurrency: + group: core-benchmarks-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} + cancel-in-progress: true + +jobs: + compare: + name: Core runtime benchmark comparison + runs-on: ubuntu-latest + timeout-minutes: 90 + env: + CXX: g++ + BUILD_JOBS: 2 + ARTIFACT_DIR: ${{ github.workspace }}/core-benchmark-artifacts + + steps: + - name: Checkout candidate repository + uses: actions/checkout@v4 + with: + fetch-depth: 0 + submodules: recursive + + - name: Install benchmark dependencies + run: | + set -euxo pipefail + sudo apt-get update -y + sudo apt-get install -y --no-install-recommends \ + build-essential cmake ninja-build mold pkg-config python3 jq git \ + libssl-dev zlib1g-dev nlohmann-json3-dev libspdlog-dev libfmt-dev + + - name: Resolve BASE and candidate commits + id: refs + run: | + set -euxo pipefail + if [ "${{ github.event_name }}" = "pull_request" ]; then + base_ref='${{ github.event.pull_request.base.sha }}' + candidate_ref='${{ github.event.pull_request.head.sha }}' + else + base_ref='${{ inputs.base_ref }}' + candidate_ref='${{ inputs.candidate_ref }}' + base_ref="${base_ref:-${{ github.event.repository.default_branch }}}" + candidate_ref="${candidate_ref:-${GITHUB_SHA}}" + fi + + echo "base_sha=$(git rev-parse "${base_ref}^{commit}")" >> "$GITHUB_OUTPUT" + echo "candidate_sha=$(git rev-parse "${candidate_ref}^{commit}")" >> "$GITHUB_OUTPUT" + + - name: Create isolated BASE and candidate worktrees + env: + BASE_SHA: ${{ steps.refs.outputs.base_sha }} + CANDIDATE_SHA: ${{ steps.refs.outputs.candidate_sha }} + run: | + set -euxo pipefail + base_dir=/tmp/vix-bench-base + candidate_dir=/tmp/vix-bench-candidate + rm -rf "$base_dir" "$candidate_dir" + git worktree add --detach "$base_dir" "$BASE_SHA" + git worktree add --detach "$candidate_dir" "$CANDIDATE_SHA" + git -C "$base_dir" submodule update --init --recursive + git -C "$candidate_dir" submodule update --init --recursive + + - name: Benchmark BASE and candidate on this runner + id: benchmark + env: + BASE_SHA: ${{ steps.refs.outputs.base_sha }} + CANDIDATE_SHA: ${{ steps.refs.outputs.candidate_sha }} + run: | + set -euxo pipefail + mkdir -p "$ARTIFACT_DIR" + + capture_environment() { + local source_dir="$1" + local label="$2" + local output="$3" + SOURCE_DIR="$source_dir" LABEL="$label" OUTPUT="$output" python3 - <<'PY' + import json, os, platform, subprocess + def command(*args): + return subprocess.check_output(args, text=True).strip() + data = { + "label": os.environ["LABEL"], + "commit": command("git", "-C", os.environ["SOURCE_DIR"], "rev-parse", "HEAD"), + "cpu_model": command("bash", "-lc", "lscpu | sed -n 's/^Model name:[[:space:]]*//p' | head -1"), + "cpu_count": os.cpu_count(), + "memory": command("bash", "-lc", "free -b | awk '/Mem:/ {print $2}'"), + "kernel": platform.release(), + "compiler_path": command("bash", "-lc", "command -v \"${CXX:-g++}\""), + "compiler": command(os.environ.get("CXX", "g++"), "--version").splitlines()[0], + "linker": command("bash", "-lc", "mold --version 2>/dev/null || ld --version | head -1"), + "cmake": command("cmake", "--version").splitlines()[0], + "ninja": command("ninja", "--version"), + "build_type": "Release", + "generator": "Ninja", + "build_jobs": os.environ.get("BUILD_JOBS"), + } + with open(os.environ["OUTPUT"], "w", encoding="utf-8") as f: + json.dump(data, f, indent=2) + f.write("\n") + PY + } + + build_and_run() { + local label="$1" + local source_dir="$2" + local build_dir="/tmp/vix-bench-build-${label}" + local result_dir="$ARTIFACT_DIR/${label}/runtime" + rm -rf "$build_dir" + mkdir -p "$result_dir" + + capture_environment "$source_dir" "$label" "$ARTIFACT_DIR/${label}/environment.json" + cmake -S "$source_dir/modules/core" -B "$build_dir" -G Ninja \ + -DCMAKE_BUILD_TYPE=Release \ + -DCMAKE_CXX_COMPILER="$CXX" \ + -DCMAKE_EXE_LINKER_FLAGS=-fuse-ld=mold \ + -DVIX_CORE_BUILD_BENCHMARKS=ON \ + -DVIX_CORE_BUILD_TESTS=OFF \ + -DVIX_CORE_ENABLE_INSTALL=OFF + cmake --build "$build_dir" --target core_benchmarks --parallel "$BUILD_JOBS" + "$source_dir/modules/core/scripts/run_core_benchmarks.sh" \ + --bin-dir "$build_dir/benchmarks/core" \ + --out-dir "$result_dir" \ + --version "$(git -C "$source_dir" rev-parse --short HEAD)" \ + --runner "github-actions-${GITHUB_RUN_ID}" \ + --machine "${RUNNER_OS}-${RUNNER_ARCH}" + + # This is intentionally a compile-only consumer target: no ccache and no link. + local consumer_dir="/tmp/vix-bench-consumer-${label}" + rm -rf "$consumer_dir" + mkdir -p "$consumer_dir" + cat > "$consumer_dir/CMakeLists.txt" < "$consumer_dir/main.cpp" <<'EOF' + #include + + int main() + { + vix::App app; + app.get("/health", [](vix::Request&, vix::ResponseWrapper&) {}); + return 0; + } + EOF + cmake -S "$consumer_dir" -B "$consumer_dir/build" -G Ninja \ + -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER="$CXX" \ + -DVIX_CORE_BUILD_BENCHMARKS=OFF -DVIX_CORE_BUILD_TESTS=OFF \ + -DVIX_CORE_ENABLE_INSTALL=OFF + CCACHE_DISABLE=1 /usr/bin/time -v ninja -C "$consumer_dir/build" \ + CMakeFiles/vix_compile_consumer.dir/main.cpp.o \ + > "$ARTIFACT_DIR/${label}/compile-consumer.stdout" \ + 2> "$ARTIFACT_DIR/${label}/compile-consumer.time" + } + + build_and_run base /tmp/vix-bench-base + build_and_run candidate /tmp/vix-bench-candidate + + cmp \ + <(jq 'del(.label, .commit)' "$ARTIFACT_DIR/base/environment.json") \ + <(jq 'del(.label, .commit)' "$ARTIFACT_DIR/candidate/environment.json") + + set +e + python3 modules/core/scripts/compare_core_benchmarks.py \ + "$ARTIFACT_DIR/base/runtime" "$ARTIFACT_DIR/candidate/runtime" \ + --json-out "$ARTIFACT_DIR/comparison.json" \ + > "$ARTIFACT_DIR/comparison.txt" 2>&1 + comparison_exit=$? + set -e + echo "comparison_exit=$comparison_exit" >> "$GITHUB_OUTPUT" + if [ "$comparison_exit" -eq 2 ]; then + cat "$ARTIFACT_DIR/comparison.txt" + exit 2 + fi + + - name: Publish benchmark summary + if: always() + env: + BASE_SHA: ${{ steps.refs.outputs.base_sha }} + CANDIDATE_SHA: ${{ steps.refs.outputs.candidate_sha }} + COMPARISON_EXIT: ${{ steps.benchmark.outputs.comparison_exit }} + run: | + set -euo pipefail + if [ ! -f "$ARTIFACT_DIR/comparison.json" ]; then + echo "# Vix Core Benchmarks" >> "$GITHUB_STEP_SUMMARY" + echo "Benchmark comparison did not complete; inspect the uploaded logs." >> "$GITHUB_STEP_SUMMARY" + exit 0 + fi + python3 - <<'PY' >> "$GITHUB_STEP_SUMMARY" + import json, os, pathlib, re + from collections import defaultdict + root = pathlib.Path(os.environ["ARTIFACT_DIR"]) + print("# Vix Core Benchmarks") + print() + print(f"Base: `{os.environ['BASE_SHA']}` ") + print(f"Candidate: `{os.environ['CANDIDATE_SHA']}`") + report = json.loads((root / "comparison.json").read_text()) + results = report["results"] + improved = sum(r["status"] == "OK" and r["change_percent"] > 0 for r in results) + stable = sum(r["status"] == "OK" and r["change_percent"] <= 0 for r in results) + print() + print(f"{len(results)} benchmarks β€” improved: {improved}, stable: {stable}, warn: {report['summary']['warn']}, regressed: {report['summary']['fail']}") + print() + groups = defaultdict(lambda: {"total": 0, "warn": 0, "regressed": 0}) + for item in results: + group = item["benchmark"].split("/", 1)[0] + groups[group]["total"] += 1 + groups[group]["warn"] += item["status"] == "WARN" + groups[group]["regressed"] += item["status"] == "FAIL" + print("| Group | Cases | Warn | Regressed |") + print("| --- | ---: | ---: | ---: |") + for group, counts in sorted(groups.items()): + print(f"| `{group}` | {counts['total']} | {counts['warn']} | {counts['regressed']} |") + print() + print("| Status | Delta | Benchmark |") + print("| --- | ---: | --- |") + for item in results: + status = "REGRESSED" if item["status"] == "FAIL" else item["status"] + delta = "-" if item["change_percent"] is None else f"{item['change_percent']:+.2f}%" + print(f"| {status} | {delta} | `{item['benchmark']}` |") + for label in ("base", "candidate"): + time_file = root / label / "compile-consumer.time" + text = time_file.read_text() if time_file.exists() else "unavailable" + wall = re.search(r"Elapsed \(wall clock\) time .*: (.+)", text) + rss = re.search(r"Maximum resident set size \(kbytes\): (\d+)", text) + print(f"\nCompile consumer ({label}, ccache disabled): wall={wall.group(1) if wall else 'n/a'}, max RSS={rss.group(1) if rss else 'n/a'} KiB") + PY + if [ "${COMPARISON_EXIT:-0}" = "1" ]; then + echo "::warning::Core benchmark comparison contains WARN/REGRESSED results; inspect the same-runner artifact." + fi + + - name: Upload BASE, candidate, and comparison artifacts + if: always() + uses: actions/upload-artifact@v4 + with: + name: core-benchmarks-${{ github.run_id }}-${{ github.run_attempt }} + path: core-benchmark-artifacts/ + if-no-files-found: warn diff --git a/modules/cli b/modules/cli index 7f527d5..8884c30 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 7f527d502be0c45bad76d1d91992197fda566fcd +Subproject commit 8884c305ff654e85669043b0d45ac60885fbc5cc diff --git a/modules/core b/modules/core index e69428c..0709d93 160000 --- a/modules/core +++ b/modules/core @@ -1 +1 @@ -Subproject commit e69428cec5413d527346e4f55ee6fccaa171c82a +Subproject commit 0709d938e3f3a02041c594676982978d49be6a29 diff --git a/modules/engine b/modules/engine index aaad94e..9fd6c55 160000 --- a/modules/engine +++ b/modules/engine @@ -1 +1 @@ -Subproject commit aaad94e52562ac7bd905892c87926530afd75014 +Subproject commit 9fd6c5549a52d55dd1aa3181608b02e40d401467 diff --git a/modules/websocket b/modules/websocket index 6b9b04d..00cbc81 160000 --- a/modules/websocket +++ b/modules/websocket @@ -1 +1 @@ -Subproject commit 6b9b04de017937919aa5511f1f8b96fbc34a7ac6 +Subproject commit 00cbc81336b2cabc178a88dd42658c1ffb7a9def From ae3a1f370b2e832e3ed4d597d0db9cc91079eb6a Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Thu, 13 Aug 2026 10:23:15 +0300 Subject: [PATCH 13/19] fix(core): update core module with stability fixes --- modules/core | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/core b/modules/core index 0709d93..1e1b2fb 160000 --- a/modules/core +++ b/modules/core @@ -1 +1 @@ -Subproject commit 0709d938e3f3a02041c594676982978d49be6a29 +Subproject commit 1e1b2fb1525e33ba7cefa3f2800290420d0c6878 From 9b34659a592e6a98209cb19fcbaa62f6ce291d63 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Thu, 13 Aug 2026 11:40:40 +0300 Subject: [PATCH 14/19] fix(release): update cli help and websocket export handling --- modules/cli | 2 +- modules/websocket | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/cli b/modules/cli index 8884c30..5ce4317 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 8884c305ff654e85669043b0d45ac60885fbc5cc +Subproject commit 5ce431725190b18644ac156b83f1a4646046e9c0 diff --git a/modules/websocket b/modules/websocket index 00cbc81..a61432a 160000 --- a/modules/websocket +++ b/modules/websocket @@ -1 +1 @@ -Subproject commit 00cbc81336b2cabc178a88dd42658c1ffb7a9def +Subproject commit a61432a1614bba598f0802392cd08f7fe9b65173 From e9071ef0b67e75d0206ce21b3d215caec59a46fe Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Thu, 13 Aug 2026 12:03:21 +0300 Subject: [PATCH 15/19] fix(release): update core config shared_ptr handling --- modules/core | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/core b/modules/core index 1e1b2fb..160d7f4 160000 --- a/modules/core +++ b/modules/core @@ -1 +1 @@ -Subproject commit 1e1b2fb1525e33ba7cefa3f2800290420d0c6878 +Subproject commit 160d7f4a3d1aea5ec1618db2a812829fb3170c4d From fd910a1536baebbee8afe6eb523613200293a4a1 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Thu, 13 Aug 2026 14:13:27 +0300 Subject: [PATCH 16/19] fix(release): update cli build help and run contract --- modules/cli | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/cli b/modules/cli index 5ce4317..ff0785b 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit 5ce431725190b18644ac156b83f1a4646046e9c0 +Subproject commit ff0785b8ab9a1987e46497e2bb073c4b84302f6b From 9e08f2a40b791dc7a3da311f03e2d6d2e386574d Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Thu, 13 Aug 2026 16:25:09 +0300 Subject: [PATCH 17/19] fix(release): update cli umbrella run contract --- modules/cli | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/cli b/modules/cli index ff0785b..c1a9fd7 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit ff0785b8ab9a1987e46497e2bb073c4b84302f6b +Subproject commit c1a9fd7fa4a1357e78209557f5732036293612c4 From 2f328b9968440a6658f8d6f974b53119bec18c33 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Thu, 13 Aug 2026 20:36:01 +0300 Subject: [PATCH 18/19] fix(release): update cli dev coroutine lifetime handling --- modules/cli | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/cli b/modules/cli index c1a9fd7..a6cee2f 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit c1a9fd7fa4a1357e78209557f5732036293612c4 +Subproject commit a6cee2ff1c74580b9b78d01ba1ceee1da1830fdd From 98bac0aa84de09d499c2f3d2e1eb30f6e3a40820 Mon Sep 17 00:00:00 2001 From: Gaspard Kirira Date: Fri, 14 Aug 2026 09:45:44 +0300 Subject: [PATCH 19/19] chore(release): prepare v2.8.4 --- CHANGELOG.md | 148 +++++++++++++++++---------- README.md | 275 +++++++++++++++------------------------------------ modules/cli | 2 +- modules/core | 2 +- 4 files changed, 179 insertions(+), 248 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index ab91d69..26d8c25 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,7 +7,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 # Vix v2.8.4 -Vix v2.8.4 improves the everyday C++ development loop with faster builds, lighter public headers, safer caching, better diagnostics, and more consistent `build`, `run`, and `dev` behavior. +Vix v2.8.4 improves the everyday C++ development loop with faster compilation and rebuilds, lighter public headers, safer caching, better diagnostics, and more consistent `build`, `run`, and `dev` behavior. ## Added @@ -15,26 +15,26 @@ Vix v2.8.4 improves the everyday C++ development loop with faster builds, lighte `vix build` now uses a compact and consistent live build interface across native, graph-executor, and CMake/Ninja builds. -* `vix build` and `vix build -v` share the same presentation. -* `-v` adds useful toolchain and build information. -* `--debug` exposes structured Vix diagnostics. -* `--cmake-verbose` remains available for raw CMake/Ninja/compiler output. -* Build logs can be inspected directly with `vix build --log`. +- `vix build` and `vix build -v` share the same presentation. +- `-v` adds useful toolchain and build information. +- `--debug` exposes structured Vix diagnostics. +- `--cmake-verbose` remains available for raw CMake/Ninja/compiler output. +- Build logs can be inspected directly with `vix build --log`. ### Better cross-compilation support -* `--target native` explicitly selects the host platform. -* `--targets` discovers available native and cross toolchains. -* `--sysroot` is available for target toolchains. +- `--target native` explicitly selects the host platform. +- `--targets` discovers available native and cross toolchains. +- `--sysroot` is available for target toolchains. ### Explicit `vix run` controls Added documented CLI options for runtime behavior previously controlled primarily through internal or environment-based configuration: -* `--ui` / `--no-ui` -* `--env-hint` / `--no-env-hint` -* `--trace-cache` / `--no-trace-cache` -* `--compiler-fingerprint ` +- `--ui` / `--no-ui` +- `--env-hint` / `--no-env-hint` +- `--trace-cache` / `--no-trace-cache` +- `--compiler-fingerprint ` ## Improved @@ -42,66 +42,108 @@ Added documented CLI options for runtime behavior previously controlled primaril Vix public headers have been significantly reduced and decoupled from heavy implementation details. -* `App` no longer exposes Router, HTTPServer, RequestHandler, runtime executor, or Asio internals unnecessarily. -* `core.hpp` no longer pulls advanced HTTP/router implementation headers into every `` consumer. -* JSON-heavy `Config` and response implementation has been moved out of public headers where possible. -* Logger internals no longer expose spdlog throughout user translation units. -* Public APIs such as GET routes, POST JSON, middleware, Config, and logging remain compatible. +- `App` no longer exposes Router, HTTPServer, RequestHandler, runtime executor, or Asio internals unnecessarily. +- `core.hpp` no longer pulls advanced HTTP/router implementation headers into every `` consumer. +- JSON-heavy `Config` and response implementation has been moved out of public headers where possible. +- Logger internals no longer expose spdlog throughout user translation units. +- `RuntimeExecutor` lifecycle implementation is now kept out of user translation units where possible. +- Public APIs such as GET routes, POST JSON, middleware, Config, logging, and runtime executors remain compatible. -This substantially reduces compiler CPU time and memory usage for applications using ``. +These changes reduce compiler work and memory pressure for applications using Vix public headers. ### Faster `vix run` Standalone C++ programs keep the lightweight direct compilation path, while programs requiring compiled Vix runtime functionality use the correct CMake-backed path. -Warm executions reuse validated build state and compiled artifacts without unnecessary recompilation. +- Warm executions reuse validated build state and compiled artifacts. +- Cache validation avoids redundant work in the direct script path. +- Local and transitive dependencies remain correctly tracked. +- Unchanged scripts can run without invoking the compiler or linker. + +### Faster and cleaner `vix dev` + +`vix dev` now provides a faster and more focused development loop for both standalone C++ files and full Vix projects. + +For standalone files, the normal output is intentionally minimal: + +```text +Watching test.cpp +Hello, world +Rebuilt test.cpp in 488ms +Hello, world +``` + +- Single-file rebuilds reuse the optimized direct compilation path. +- Rebuild output no longer exposes unnecessary process IDs, absolute paths, or internal reload messages. +- Build progress is shown only when useful instead of cluttering fast rebuilds. +- Rebuild duration is reported directly in the terminal. +- Application output follows rebuild status without unnecessary blank lines. +- Source and transitive-header changes trigger a single rebuild/restart. +- Failed builds recover cleanly after the source is corrected. + +Project `vix dev` also reports the real rebuild duration while retaining the full project build experience: + +```text +Dev shop (dev) + + changed: src/main.cpp + + build [============================] done + + βœ” Rebuilt in 7.3s Β· Started pid=49809 +``` + +`vix dev` and `vix build --watch` now follow the same underlying build behavior rather than maintaining fragmented rebuild paths. ### Dependency-aware caching Script caching now correctly tracks source files and local/transitive headers by content. -* Header changes invalidate affected builds. -* Touching an unchanged file does not unnecessarily rebuild. -* Failed compilations are not reused as cache hits. -* Compiled dependency graphs are rebuilt only when required. +- Header changes invalidate affected builds. +- Touching an unchanged file does not unnecessarily rebuild. +- Failed compilations are not reused as cache hits. +- Compiled dependency graphs are rebuilt only when required. +- Previously compiled source states can be restored efficiently through the compiler cache. -### Better `vix dev` +### Safer build parallelism -`vix dev` now handles source and transitive-header changes more reliably. +Automatic build parallelism now keeps part of the machine available instead of consuming every hardware thread by default. -* Dependency changes trigger a single rebuild/restart. -* Content changes are detected even on filesystems with coarse timestamps. -* Dependency sets are refreshed after successful rebuilds. -* Shutdown and interruption handling is more predictable. +- Build jobs adapt to the available CPU resources. +- Interactive development remains more responsive during large builds. +- Explicit `--jobs` values continue to override the automatic recommendation. ## Fixed -* Fixed incomplete linkage when running code that depends on compiled Vix libraries. -* Fixed transitive compiled dependency rebuilding. -* Fixed stale script/build cache decisions. -* Fixed generated CMake target handling for script builds. -* Fixed `--fast` builds incorrectly missing reusable configuration state. -* Fixed graph-executor builds being bypassed by unrelated cache paths. -* Fixed linker diagnostics for missing implementations and libraries. -* Fixed build-log selection when a build directory is provided. -* Fixed server startup reporting so `READY` is emitted only after successful startup. -* Fixed port configuration and bind-error propagation. -* Fixed local build-tree CMake package exports so Vix can be consumed directly from the current build without falling back to an installed runtime. +- Fixed incomplete linkage when running code that depends on compiled Vix libraries. +- Fixed transitive compiled dependency rebuilding. +- Fixed stale script/build cache decisions. +- Fixed redundant cache validation in standalone script execution. +- Fixed generated CMake target handling for script builds. +- Fixed `--fast` builds incorrectly missing reusable configuration state. +- Fixed graph-executor builds being bypassed by unrelated cache paths. +- Fixed linker diagnostics for missing implementations and libraries. +- Fixed build-log selection when a build directory is provided. +- Fixed server startup reporting so `READY` is emitted only after successful startup. +- Fixed port configuration and bind-error propagation. +- Fixed local build-tree CMake package exports so Vix can be consumed directly from the current build without falling back to an installed runtime. +- Fixed missing direct header dependencies exposed after reducing public transitive includes. ## Summary -Vix v2.8.4 makes the development loop faster and more predictable: - -* lighter C++ compilation; -* fast warm `vix run`; -* safer dependency-aware caching; -* more reliable `vix dev`; -* correct compiled-library linkage; -* clearer build and linker diagnostics; -* consistent build output; -* improved local and cross-platform tooling. - - +Vix v2.8.4 makes the C++ development loop faster and more predictable: + +- lighter public headers and faster C++ compilation; +- faster standalone rebuilds; +- fast warm `vix run`; +- compact and timed `vix dev` reloads; +- safer dependency-aware caching; +- adaptive build parallelism; +- reliable source and header watching; +- correct compiled-library linkage; +- clearer build and linker diagnostics; +- consistent behavior across `build`, `run`, and `dev`; +- improved local and cross-platform tooling. # Vix v2.8.3, v2.8.2, v2.8.1 diff --git a/README.md b/README.md index b7581e2..7e368cb 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@

Vix.cpp

- A modern C++ runtime for building fast and reliable applications. + A C++ developer platform for building native applications.

@@ -22,9 +22,17 @@ Engineering Notes

-Vix.cpp brings the work around native C++ applications into one coherent workflow. It provides a runtime, a command-line interface, SDK profiles, package management, diagnostics, testing, packaging, and production-oriented tooling without changing the language or hiding the native toolchain. +Vix.cpp brings the tools around a C++ application into one coherent workflow. You can use it to run and build projects, manage dependencies, work with application modules, run tests, inspect problems, package applications and prepare them for production. -A Vix project remains an ordinary C++ project. It is compiled by a C++ compiler, can interoperate with CMake and existing build systems, and produces native executables and libraries. Vix exists to make the path from source code to a working application more direct, repeatable, and understandable. +Vix does not introduce a new language or hide the native C++ toolchain. A Vix project is still compiled by a C++ compiler, can work with CMake and existing libraries, and produces normal native executables and libraries. + +## Why Vix exists + +C++ already gives developers excellent compilers, native performance and a large ecosystem. The difficult part often starts when a program becomes an application. + +A project needs a build configuration. Then dependencies, tests, development commands, diagnostics, packaging and eventually production tooling appear. There are good tools for each of these problems, but developers still have to assemble them and maintain the workflow between them. + +Vix exists to make that workflow more consistent without replacing the C++ ecosystem underneath it.

-## Why Vix exists - -C++ already provides mature compilers, native performance, a large ecosystem, and decades of production use. The difficult part is often everything that must be assembled around the language before a project feels like a complete application. - -Even a small project quickly accumulates decisions about directory layout, build configuration, dependency resolution, test execution, development mode, diagnostics, packaging, deployment, CI, and reproducibility across machines. Each tool can solve part of that problem, but the developer is still responsible for turning those separate parts into a consistent workflow. - -Vix exists to provide that workflow. It gives C++ projects a common way to be created, run, built, tested, checked, packaged, upgraded, and prepared for production while keeping the underlying compiler, build files, dependencies, and native outputs visible. +## Try it -## Install Vix - -Vix is installed in two stages. The install script bootstraps the CLI, then the CLI installs the SDK profile required by the project. - -### Linux and macOS +Install Vix on Linux or macOS: ```bash curl -fsSL https://vixcpp.com/install.sh | bash ``` -### Windows PowerShell +On Windows PowerShell: ```powershell irm https://vixcpp.com/install.ps1 | iex ``` -Confirm the installation: +Check the installation: ```bash vix --version ``` -Then inspect the available SDK profiles and install the one that matches the application you are building: +You can start with a normal C++ file. -```bash -vix upgrade --sdk list -vix upgrade --sdk info web -vix upgrade --sdk web -``` - -The [installation guide](https://docs.vixcpp.com) covers platform requirements, PATH configuration, SDK profiles, upgrades, and troubleshooting. - -## The Vix workflow +```cpp +#include -The Vix CLI is the main entry point into the platform. It understands Vix projects, standalone C++ files, application manifests, SDK profiles, registry dependencies, build state, diagnostics, tests, and production workflows. - -

- Vix.cpp CLI commands -

+int main() +{ + std::cout << "Hello from Vix.cpp\n"; +} +``` -The command surface follows the lifecycle of an application. The same tool can create a project, run it during development, build native outputs, execute tests, inspect problems, manage packages, prepare releases, and update the installed SDK. +Run it with: ```bash -vix --help -vix help +vix run main.cpp ``` -The README intentionally does not reproduce the complete command reference. Detailed command behavior, options, examples, and project formats are maintained in the [official documentation](https://docs.vixcpp.com). +There is no separate execution model here. Vix builds and runs native C++. -## Vix Reply +When the project becomes larger, the same CLI can work with complete applications: -

- Vix Reply interactive C++ REPL -

- -Vix Reply provides an interactive terminal for experimenting with C++, running native snippets, and receiving structured compiler diagnostics without creating a project first. - -## Native C++ remains visible - -Vix is not a successor to C++, a new language syntax, or a separate compiler model. It does not turn C++ into an interpreted environment, and it does not place applications inside a closed runtime. - -It is also not a replacement for CMake. Existing CMake projects can keep their current structure and use Vix around it. New applications that do not need custom CMake logic can begin with a simpler Vix application manifest and still produce normal native build outputs. +```bash +vix init +vix run +vix build +vix tests +vix check +``` -This distinction is central to the project. Vix improves the application workflow around C++; it does not remove the tools, formats, or knowledge that make a C++ project portable and maintainable. +The [installation guide](https://docs.vixcpp.com) explains SDK profiles, platform requirements and the complete setup process. -## Runtime and application modules +## From a C++ project to an application -Vix is not only a CLI wrapped around a compiler. It ships runtime modules that cover the infrastructure real native applications usually have to assemble by hand: HTTP routing, middleware, async execution, WebSocket support, configuration, environment files, filesystems, processes, databases, serialization, caching, validation, logging, testing, packaging, and diagnostics. +Vix is more than a command that invokes a compiler. The platform includes runtime modules and development tooling for the things real applications commonly need, including HTTP, middleware, asynchronous execution, WebSockets, configuration, filesystems, processes, databases, serialization, caching, validation and logging. -The important part is that these modules are designed to compose as one platform. A backend can use the HTTP runtime, middleware, database layer, validation, logging, environment loading, and tests without each piece introducing a different project model or error style. Existing CMake projects can adopt the modules directly. New Vix applications can use the app-first workflow. +These parts are designed to work together instead of giving every library its own project structure and development workflow. -For generated applications, `vix.app` is the readable source of truth at the project root. It describes the native target, C++ standard, source files, include directories, linked Vix modules, registry dependencies, compile options, resources, output directory, and enabled application modules. Vix reads that manifest, generates an internal CMake project under `.vix/generated/app/`, and still builds through the normal native toolchain. The generated files are inspectable when debugging, but the project remains driven by the manifest. +For Vix-managed applications, the project can be described with `vix.app`: ```ini name = "api" @@ -130,13 +108,6 @@ standard = "c++20" sources = [ "src/main.cpp", - "src/app/AppBootstrap.cpp", - "src/presentation/routes/RouteRegistry.cpp", -] - -include_dirs = [ - "include", - "src", ] packages = [ @@ -146,57 +117,33 @@ packages = [ links = [ "vix::vix", ] - -[module.auth] -enabled = true -path = "modules/auth" -kind = "backend" -depends = [] ``` -### Git dependencies with `vix.app` +Vix reads the application description and generates the native build it needs internally. The generated files remain inspectable, and projects that need custom CMake logic can continue using CMake directly. -For an existing folder, `vix init` creates a minimal `vix.app` from the current project: +## Dependencies -```bash -vix init -``` +Existing C++ libraries can be used from a Vix project. -A Git dependency can then be added directly from its repository: +For example: ```bash vix install https://github.com/fmtlib/fmt ``` -Vix detects the latest stable version and the public CMake target, then records them in `vix.app`: +Vix can detect the dependency information, add it to the application and preserve the resolved commit in `vix.lock`. -```toml -name = "fmt-test" -type = "executable" -standard = "c++20" -sources = ["main.cpp"] - -[dependencies.fmt] -git = "https://github.com/fmtlib/fmt" -tag = "12.2.0" -target = "fmt::fmt" -``` - -The exact commit is preserved in `vix.lock`, and the dependency is prepared automatically when the project is built or run: - -```bash -vix run main.cpp -``` - -For a temporary test without modifying `vix.app`: +A dependency can also be used temporarily without modifying the application: ```bash vix run main.cpp --dep https://github.com/fmtlib/fmt ``` -### Application modules +The goal is not to create a separate library ecosystem. Dependencies remain native C++ dependencies and participate in the normal build. -Application modules let a large Vix application remain a single native process while keeping features such as `auth`, `projects`, `billing`, `logs`, or `deployments` behind explicit public and private boundaries. +## Application modules + +Large applications can be divided into modules while remaining a single native application. ```bash vix modules init @@ -206,134 +153,76 @@ vix modules check vix build ``` -Each module owns its public headers, private implementation, tests, dependencies, metadata, route prefix, and CMake target. Enabled modules are declared in `vix.app`, and Vix generates the registration and linking code required by the application. - -WebSocket modules can be created with dedicated workflows: - -```bash -vix modules add notifications --websocket --workflow attached -vix modules add gateway --websocket --workflow standalone -vix modules add bridge --websocket --workflow bridge -vix modules add client --websocket --workflow client -``` - -`vix modules check` validates module structure, explicit dependencies, enabled state, dependency cycles, duplicate route ownership, and public headers that expose private implementation paths. +A module can own its public interface, private implementation, tests and dependencies. Vix validates the relationships between modules and generates the registration and linking code required by the application. -See the [module documentation](https://docs.vixcpp.com), [vix.app guide](https://docs.vixcpp.com/guides/vix-app), and [application modules guide](https://docs.vixcpp.com/app-modules) for the complete reference. +This gives larger C++ applications explicit boundaries without requiring every feature to become a separate service or process. -## Production deployment workflows +## Native C++ stays visible -Vix provides production workflows for building, testing, restarting services, checking application health, validating Nginx configuration, inspecting failure logs, and rolling back failed Git deployments. +Vix is not a replacement for C++, CMake or the compiler. -```bash -vix deploy --dry-run -vix deploy -vix doctor production -``` +Existing CMake projects can keep their current structure and use Vix around them. New projects can start with `vix.app` when they do not need custom build logic. -Deployment behavior is configured in `vix.json`, while the application, compiler, service, and production infrastructure remain under the developer’s control. +In both cases, the important parts remain accessible to the developer: compiler diagnostics, dependencies, generated build files and native outputs. -## SDK profiles and the Vix Registry +Vix tries to remove repetitive work around C++ without making the underlying system mysterious. -SDK profiles define coherent development environments for different kinds of Vix applications. They allow the CLI, runtime modules, build configuration, and supporting tools to be installed and upgraded together instead of being assembled manually on every machine. +## Developer tools -The [Vix Registry](https://registry.vixcpp.com) provides reusable C++ packages that can be added to applications through the Vix dependency workflow. Registry packages remain native C++ dependencies and integrate with normal project builds. +Vix also includes tools for working with C++ outside the normal edit, build and run cycle. -Together, SDK profiles and the registry make it easier to reproduce the same project environment locally, in CI, and across a team without turning the project into a closed ecosystem. +**Vix Reply** is an interactive terminal for experimenting with native C++ and inspecting compiler diagnostics. -## Vix Note - -

- Vix Note interface -

+```bash +vix repl +``` -Vix Note is a visual workspace for executable notes, experiments, and diagnostics. Its extension system allows packages to add new cell types, runtimes, and developer tools such as Python execution or C++ memory visualization. +**Vix Note** is a visual workspace for executable notes, experiments and developer tooling. ```bash vix note ``` -## Softadastra Cloud +They use the same C++ environment as the rest of the platform rather than introducing another language or runtime. -[Softadastra Cloud](https://cloud.softadastra.com) is the product layer built around Vix for private C++ packages and team project operations. It gives C++ projects a controlled cloud workspace for the parts of development that need to be shared: workspaces, private packages, package versions, lockfiles, build reports, permissions, access tokens, public profiles, and team activity. +## Production -Vix keeps the project local. The compiler, source files, build outputs, and native workflow stay on the developer machine or inside the team’s own CI environment. Softadastra Cloud adds the shared state around that workflow, so a project can move from one developer to a team without losing visibility into what was published, which lockfile was used, which build failed, and who has access. +The workflow continues beyond local development. ```bash -vix login -vix cloud init -vix cloud status -vix cloud lockfile upload -vix build --report -vix publish --cloud +vix deploy --dry-run +vix deploy +vix doctor production ``` -This connection matters because Vix is not designed only from small examples. It is exercised through a real product workflow where the CLI, manifests, private package archives, lockfiles, build reports, permissions, and project metadata have to work together. - -Softadastra Cloud keeps native C++ projects understandable after they leave a single machine. Developers can see what exists, what changed, what private package was published, what failed, and which parts of the project are private or public, while the local-first nature of Vix remains intact. - -Use [cloud.softadastra.com](https://cloud.softadastra.com) to create a workspace, publish private packages, and connect a Vix project to the team workflow. - -## Project direction - -

- Vix.cpp project direction -

- -Vix.cpp v2.7 marks an important foundation point for the project. The next phase is centered on improving what already exists rather than continuously expanding the platform with new modules. - -The work now focuses on module quality, registry reliability, SDK installation, diagnostics, tests, CI coverage, release quality, examples, documentation, and validation through real applications. This direction is about maturity: fewer unnecessary additions, more depth, better maintenance, and stronger confidence in the complete workflow. +Vix can help with build and test checks, service restarts, application health, production diagnostics and deployment recovery while leaving the application infrastructure under the developer's control. -New capabilities can still be added, but they should solve a practical application problem, improve an existing workflow, or strengthen a part of the platform that developers already depend on. +## Registry -## Projects around Vix.cpp +The [Vix Registry](https://registry.vixcpp.com) provides reusable C++ packages that can be installed through the Vix dependency workflow. -Vix.cpp remains the native foundation. Higher-level libraries, runtimes, and developer tools can grow around it without making the core platform lose focus. +Packages remain normal native dependencies. Together with `vix.lock` and SDK profiles, this makes it easier to reproduce the same project environment on another machine or in CI. -**[Rix](https://rix.vixcpp.com)** is the optional userland library layer for Vix applications. It provides application-level packages and a unified facade above the core Vix runtime. +## Documentation -**[Cnerium](https://github.com/softadastra/cnerium)** is a reliability-first backend layer for Vix. It provides a place for backend structure and production-oriented patterns to evolve without turning the core runtime into a large opinionated framework. +This README is only an introduction to the project. -**[Kordex](https://github.com/softadastra/kordex)** is a JavaScript runtime for reliable local-first applications built on Vix.cpp. It demonstrates how the native platform can support higher-level runtimes while preserving a C++ foundation. +The [Vix.cpp documentation](https://docs.vixcpp.com) covers the application model, CLI, build workflow, runtime, modules, dependencies, SDK profiles, testing, production workflows and internal architecture in more detail. -**[Cgride](https://github.com/cgride/cgride)** is an embeddable native C++ build engine configured in C++. It provides project modeling, toolchain discovery, build graphs, incremental compilation, caching, and a minimal CLI. It is also designed for integration into runtimes and developer tools such as Vix.cpp. - -## Working on this repository - -This repository contains the Vix CLI, runtime, modules, SDK profiles, registry integration, tests, examples, release infrastructure, and documentation source. Users normally begin with the packaged CLI and the official documentation; contributors work directly from this repository. - -To build Vix.cpp from source, clone the repository with its submodules and follow the build and test instructions in the [developer documentation](https://docs.vixcpp.com). The documented workflow covers supported platforms, build options, SDK profiles, module tests, and release checks. +Technical decisions, benchmarks and engineering work are published in the [Engineering Notes](https://blog.vixcpp.com). ## Contributing -Contributions should improve the clarity, reliability, and maintainability of the existing platform. Fixes, tests, diagnostics, documentation, registry improvements, CI work, and careful refinements to current modules are especially valuable. +Vix.cpp is developed in the open. Contributions to the runtime, modules, diagnostics, tests, documentation, registry, CI, portability and performance are welcome. -For substantial changes, begin with an issue or discussion so the design can be considered in the context of the whole platform. +For larger changes, opening an issue or discussion first makes it easier to consider the design in the context of the whole platform. -See [CONTRIBUTING.md](CONTRIBUTING.md), [SECURITY.md](SECURITY.md), [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md), and [CHANGELOG.md](CHANGELOG.md) for project policies and release history. +See [CONTRIBUTING.md](CONTRIBUTING.md), [SECURITY.md](SECURITY.md), [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) and [CHANGELOG.md](CHANGELOG.md). ## Maintained by Softadastra -Vix.cpp is maintained by [Softadastra](https://softadastra.com), a company building tools that simplify modern C++ development. - -## Resources - -- [Vix.cpp documentation](https://docs.vixcpp.com): guides, commands, SDK profiles, modules, examples, and internals. -- [Vix Registry](https://registry.vixcpp.com): reusable public packages for Vix applications. -- [Softadastra Cloud](https://cloud.softadastra.com): private C++ packages, workspaces, lockfiles, build reports, access tokens, and team project activity. -- [Rix](https://rix.vixcpp.com): optional userland libraries for Vix projects. -- [Engineering Notes](https://blog.vixcpp.com): design decisions, releases, benchmarks, and technical articles. -- [Softadastra](https://softadastra.com): the company maintaining Vix.cpp. +Vix.cpp is maintained by [Softadastra](https://softadastra.com), a computing research and technology company. ## License -Vix.cpp is available under the MIT License. \ -See [LICENSE](LICENSE) for details. +Vix.cpp is available under the MIT License. See [LICENSE](LICENSE). diff --git a/modules/cli b/modules/cli index a6cee2f..0cf3528 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit a6cee2ff1c74580b9b78d01ba1ceee1da1830fdd +Subproject commit 0cf35280ea580ef96e924d4c051f8449341c0400 diff --git a/modules/core b/modules/core index 160d7f4..8134051 160000 --- a/modules/core +++ b/modules/core @@ -1 +1 @@ -Subproject commit 160d7f4a3d1aea5ec1618db2a812829fb3170c4d +Subproject commit 8134051bb9a972639f2037be93eeecbffe4bb972