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/.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..26d8c25 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,7 +5,147 @@ 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 + +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 + +### Unified `vix build` experience + +`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`. + +### Better cross-compilation support + +- `--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 ` + +## Improved + +### Faster C++ compilation + +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. +- `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. + +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. +- 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. +- Previously compiled source states can be restored efficiently through the compiler cache. + +### Safer build parallelism + +Automatic build parallelism now keeps part of the machine available instead of consuming every hardware thread by default. + +- 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 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 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 ## Added 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/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 ae6d75a..0cf3528 160000 --- a/modules/cli +++ b/modules/cli @@ -1 +1 @@ -Subproject commit ae6d75a99ad52284777a380bf34dbf2afe6f2491 +Subproject commit 0cf35280ea580ef96e924d4c051f8449341c0400 diff --git a/modules/core b/modules/core index 663472d..8134051 160000 --- a/modules/core +++ b/modules/core @@ -1 +1 @@ -Subproject commit 663472d4ee29090e73d83765e81560a3eeb5da1a +Subproject commit 8134051bb9a972639f2037be93eeecbffe4bb972 diff --git a/modules/engine b/modules/engine index 65a6baf..9fd6c55 160000 --- a/modules/engine +++ b/modules/engine @@ -1 +1 @@ -Subproject commit 65a6baf97155061cae31ffec3e9321de332311b2 +Subproject commit 9fd6c5549a52d55dd1aa3181608b02e40d401467 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 diff --git a/modules/websocket b/modules/websocket index 6b9b04d..a61432a 160000 --- a/modules/websocket +++ b/modules/websocket @@ -1 +1 @@ -Subproject commit 6b9b04de017937919aa5511f1f8b96fbc34a7ac6 +Subproject commit a61432a1614bba598f0802392cd08f7fe9b65173