v2026.10.21.1

Fixed

• Dependency-owned executable artifacts and shared libraries embed their own
  Windows resources. Resource ownership follows package identity, including
  targets with the same name in different packages; consumer resources no
  longer enter dependency images.
• Repeated planning preserves the contents and modification time of unchanged
  lockfiles, including read-only files and either LF or CRLF line endings.
  Lockfile read and write failures are reported to the caller.
• Build-database watch lists and input fingerprints exclude synthesized host
  manifests and lockfiles while retaining editable build-dependency inputs.

Documentation

• Clarify that the default module scanner reads source files without expanding
  includes. Visible imports retain their transitive module mappings; no new
  implicit-import compatibility mode is introduced.

v2026.10.19.1

Added

• mcpp self init --home <path> initializes a home and remembers it through a
  single-hop locator under the original home. --force --home changes that
  default without moving or deleting either home's data. The environment and
  portable installation retain their original home-selection precedence.
• The first interactive Windows initialization offers a writable local D drive
  and the user directory as two choices. Enter selects the displayed default;
  --home supplies another location without a prompt.
• mcpp self doctor reports resource reachability, HTTP failures and proxy use
  through the configured provider. Discovery and probes share a five-second
  deadline; offline diagnosis starts no network requests.

Fixed

• Local environment/configuration queries, toolchain listing and diagnosis no
  longer bootstrap the private registry. Mirror recovery writes local settings
  without waiting for downloads. Planning an installed toolchain does not
  require the provider's executable or initialize its home. Status queries are
  skipped when a custom provider lacks the read-only guarantee.
• First-run installations report their actual download source and candidate
  attempt. Connect, byte-idle and pre-download budgets bound network waits;
  heartbeat output cannot keep a stalled transfer alive. Parent cancellation
  stops the provider's process tree, and network failures are not repeated
  through a second install frontend.

Changed

• Bundle xlings 2026.10.19.1 with read-only network diagnostics and configurable
  download socket budgets. Verified SHA256 cache hits make no background HEAD
  request; the provider retains ownership of mirror selection and failover.
• Homebrew and Nix notifications consume the immutable sealed release manifest
  after all platform assets have been validated.

v2026.10.17.1

Fixed

• An upgrade no longer replaces installed payloads inside a build. A payload
  the index has since repackaged under the same version (a raised packaging
  revision) is used while the provider calls it usable; 2026.10.16.x
  replaced llvm, gcc (101.7 MB) and glibc (36.7 MB) on a user's next
  mcpp run. Only a payload below the version's floor, incomplete or
  missing is installed by a build, and the build says why (Updating llvm@23.1.3 packaging revision 0 → 1 (revision 0 is below the index's floor 1)). mcpp toolchain install <toolchain> takes the new packaging.
• A home with a record that points at nothing no longer fails every build.
  c++ active at a gcc version whose registration was gone made every
  replacement of llvm refuse with sysroot update refused before metadata changed: c++@16.1.0: installed asset registration missing. The bundled
  xlings drops such records in every install and mcpp reports it (Repaired c++@16.1.0 in mcpp's package home had no registration; deactivated).
• A failed install is described by its cause. A refusal the provider decided
  is said once and is neither retried through the command line nor followed by
  an index refresh; only a package the provider could not find refreshes the
  index, and the line says so (could not be installed; the index may predate it) instead of not found locally (one-time). A replacement that fails
  keeps the installed payload, and mcpp toolchain install names the
  revision still in use.
• mcpp self doctor changes nothing. It reports the toolchain a build in the
  current directory resolves (the configured default outside a package) with
  its payload's packaging revision, says when that build would install first
  instead of installing, and reports records in mcpp's package home that point
  at nothing. It used to start the build's installs and report the compiler
  on PATH as the toolchain.

Added

• mcpp index update lists installed payloads the refreshed index packages
  anew; mcpp toolchain list marks them (packaging revision 1 available),
  in --format json as installedRevision / availableRevision.
• CI: an upgrade lane (ci-upgrade.yml) builds a home with the previous
  release, read from GitHub at run time, and runs this commit's mcpp in it on
  Linux x86_64 and aarch64, macOS and Windows, with an old-index and a
  dangling-record variant on Linux.

Changed

• Bundle xlings 2026.10.17.1 (openxlings/xlings#678): payload_status
  reports integrity, usable and current apart (protocol 1.11).
• A toolchain payload's packaging revision, when above 0, is part of the
  toolchain's identity in the build fingerprint and the caches. A toolchain
  with a revision rebuilds its caches once after the upgrade.

v2026.10.16.3

Fixed

• Keep the toolchain the configuration names for this machine's own target.
  [toolchain] default with a default_target that is the host's triple (a
  Luban system's /etc/mcpp/config.toml: its gcc on aarch64-linux-gnu) was
  replaced by the target row's convention, and on aarch64 a first build
  downloaded llvm instead of using the system's gcc. A cross target and a
  capability pin are unchanged.
• gcc for a target that names glibc (aarch64-linux-gnu) is the glibc
  payload, which xim:gcc publishes for aarch64 since 16.1.0; it was
  answered with musl-gcc. With no target, aarch64 still takes musl-gcc.

v2026.10.16.2

Changed

• Bundle xlings 2026.10.16.2 (openxlings/xlings#677). Inside a Luban system,
  mcpp build uses the system's gcc: the registry builds its catalog there
  (a Landlock write fence stands in for bwrap, which cannot start inside a
  system), and a home that names upstreams borrows through them alone, so the
  borrowed toolchain has an entry in the registry's store. Before, the build
  stopped at Bootstrap patchelf/ninja ... did not complete.

v2026.10.16.1

Added

• Keep the data and payloads of each index mcpp serves in mcpp's home:
  <MCPP_HOME>/indices/<name> and <MCPP_HOME>/xpkgs (a project's in
  <project>/.mcpp). The provider's own indexes stay under registry/. A home
  from an earlier mcpp has its index data moved once; payloads already
  installed stay where they are and are still found (docs/25 §1).
• Reuse another home's packages: [xlings] upstream = ["~/.xlings"] in the
  user's config.toml, else in the system configuration
  (/etc/mcpp/config.toml). A payload of the same identity is linked, never
  copied or written; an upstream must belong to the user or to the system and
  be unwritable by the user unless it is the user's own (docs/25 §3).
• mcpp self store dedupe [--apply]: list the payloads an upstream has the
  same of, and replace each by a link.
• --system maintains the machine's system home (/var/lib/mcpp, [system] home of the system configuration) with self init|doctor|store,
  toolchain install|remove|default and index update; any other command is
  refused, and so is a caller without write access (docs/25 §4).
• windows_long_paths (target and [test] keys): longPathAware in a PE
  executable's application manifest; the default of a host tool. mcpp.exe
  declares it. With Windows long paths off and a long MCPP_HOME, the path
  budget is reported as a degradation.
• mcpp self doctor states the home: whether it is the system home, its
  upstreams, what its filesystem does, and Windows' long-path setting.
• Ask every xlings source what it is (xlings interface --version); one that
  cannot serve this mcpp gives way to the bundled xlings, with a note.

Changed

• Payloads are written by the provider alone. mcpp no longer patches a
  toolchain's ELF headers, rewrites its specs or clang .cfg, writes
  .mcpp_ok or .mcpp-fixup.json into it, or copies payloads from
  ~/.xlings. A toolchain runs on the runtime the provider bound it to through
  the registry home's runtime pin, which mcpp sets to the runtime it selected.
• Refresh an owned index into a staging directory, check its min_mcpp there,
  and exchange it with the copy in use only when this mcpp can read it. The
  backup-and-rollback of earlier versions is removed.
• Every use of xlings goes through one port (mcpp.provider); only the
  adapter under src/provider/xlings/ names xlings' commands, protocol and
  store layout, which .github/tools/check_provider_boundary.py checks.
• Publish scaffolds and index swaps by what the filesystem holding them does
  (NFSv3, SMB, FAT and FUSE included), measured once per filesystem (#809).
• Bundle xlings 2026.10.16.1, the first that places an index's data and store
  where its client names them, links from upstreams, and answers the
  handshake (openxlings/xlings#676).

Fixed

• Resolve the openkal index and runtime revisions once per run (#804).
• Accept space-separated toolchain remove specs (#808).

v2026.10.11.1

Added

• Compile build programs by their own graph (#797). The build programs of one
  build that share a host toolchain and a C++ standard are the members of one
  workspace under target/.build-mcpp/host/<group>/, planned and built like
  any workspace: a library is compiled as its package, with its include
  directories, defines, features, dependencies and implementation units, and
  build.mcpp by the same plan. mcpp build in that directory reproduces the
  compile.
• Give a [build-dependencies] entry the package's library unless it names
  tools or artifacts only; host-module = false declines it. Any library
  is importable from build.mcpp.
• Plan a package once per configuration that reaches it: a package in
  [dependencies] and [build-dependencies] has a target instance and a
  build-program instance, each with the features its own edges request, and a
  build-only package's usage requirements and link flags stay out of the
  target.
• Write the engine interface (mcpp, mcpp.core) as a package under
  $MCPP_HOME/engine/<version>/modules/, compiled into the global dependency
  cache once per version and host toolchain. mcpp self env states the
  directory as engineModules.
• Read a unit that imports mcpp.core as a build-plugin unit (SPEC-007 §10). A
  plugin's [dependencies] are compiled with it for the build program, so a
  plugin may build on plugins and libraries, and one it marks reexport = true
  is importable by its consumers' build programs; mcpp build and mcpp test in a
  plugin plan it in the build-program configuration. A plugin reached through
  a target's [dependencies], a program target that imports mcpp, --target
  for another machine on a plugin, and mcpp pack of a plugin are refused,
  naming the cause.
• Define a library's interface once (SPEC-008 v0.2): the interface root ([lib] path, the new lib key of a Form B descriptor, or src/<name>.cppm), the
  public modules it re-exports together with the interface units of active
  features, and the exported modules. [modules] exports is checked against
  the public modules, and a feature's rule_module must be declared by one of
  its units.
• Describe the build programs in mcpp emit build-database: the sets
  <package>:build, <package>:host, mcpp:core and mcpp:std:host, in the
  configuration build-program. compile_commands.json is unchanged.
• Add mcpp why build-programs and mcpp why compat (JSON kinds
  mcpp.why.build-programs and mcpp.why.compat). resolution.json and
  mcpp why deps state each package's instances.
• Keep every deprecated reading in one registry with its id, the release that
  deprecated it and the CalVer month from which it is removed. The warning
  states both releases, mcpp why compat lists the uses, --strict refuses
  them, and docs/51 lists the rows.

Changed

• Compile a build program again when its identity changes: the engine version,
  the host toolchain, the standard, the program text and every package of its
  graph, including the source tree of a path package or workspace member. An
  edited header that a library includes compiles and runs the program again.
• Remove the workspace-position reading from mcpp 2027.1 instead of 1.0.0,
  which CalVer does not reach.
• Give [xlings.overrides] and [workspace.xlings.overrides] to the root of a
  build only; a member reached as a dependency does not receive them. A member
  reached as a dependency is told about a position reading only when the
  build's root lies outside its workspace.
• Pass features and default-features of a [workspace.dependencies] entry
  to the members that inherit it, and report a request key written there
  (host-module, tools, artifacts, reexport, visibility, linkage).

Fixed

• Import from build.mcpp a module library whose interface includes the
  package's own headers (#797).
• Keep the target's library of a package listed in both [dependencies] and
  [build-dependencies] (#797).
• Keep a feature requested only by a build edge out of the target.
• Build a build plugin as the root of its own build; the engine interface was
  absent.
• Give the members of a workspace root without [package] its
  [workspace.xlings.overrides].
• Report a build.mcpp beside a workspace root without [package], and the
  schema warnings of a workspace root when its members are built.

Deprecated

• host-module-in-dependencies: a [dependencies] entry that asks for
  host-module = true or for a feature declaring rule_module is read as a
  build dependency and warned about. Removed from mcpp 2027.1.
• plugin-imports-from-build-dependencies: a plugin library that imports a
  package from its own [build-dependencies] reads that entry as a dependency
  too. Removed from mcpp 2027.1.

Removed

• The single-unit host module compile and its store
  target/.build-mcpp/host-modules/. Build programs are compiled by their
  graph.

v2026.10.10.2

Fixed

• Bundle xlings 2026.10.10.2 in the linux-x86_64 archive. The 2026.10.10.1
  archive carried xlings 2026.10.8.1, which a restored release cache provided:
  its install failures had no class and its extractions no progress. The
  release installs the pinned xlings by version and refuses a different one;
  the other archives were correct.

v2026.10.10.1

Changed

• Give a table under workspace. to every member and keep every other table
  of a manifest for its own package (#785, #786). [workspace.toolchain],
  [workspace.indices], [workspace.profile.<name>],
  [workspace.target.<selector>] with its .build, .abi, .runtime and
  .xlings.workspace subtables, and [workspace.xlings] mirror the tables of
  the same name and are read by the same reader. The merge rule belongs to the
  key: a scalar the member declared is the member's, a list puts the
  workspace's entries first, profile.<name> and target.<triple> merge key
  by key, and conditional rows are inherited ahead of the member's. A key that
  describes one package is refused under workspace., and so is an unknown
  table under [workspace].
• Keep reading a workspace root's own [toolchain], [indices],
  [profile.<name>], [target.<triple>] scalars and [xlings] entries by
  position, with the merge they had, and report each use as
  manifest/workspace-position with the [workspace.X] spelling. This
  reading is removed in mcpp 1.0.0. On a root without [package], a table
  written both ways is refused, and package tables ([build], [targets],
  [dependencies], a selector's .build, ...) are reported as acting on no
  package; --strict refuses them. A root that uses [workspace.X] without
  [workspace.package] mcpp = ">=2026.10.10.1" gets a note, because an older
  engine ignores these tables.
• Group workspace members by their configuration as it evaluates for the
  target being built, and carry a member's conditional dialect_cxxflags and
  .abi rows to the root it is planned under. A row for another target no
  longer splits two members into two graphs.
• Write the workspace layer into a published member's own tables
  ([workspace.toolchain] as [toolchain], [workspace.target.<sel>.build]
  as [target.<sel>.build]), rewriting relative paths against the package and
  refusing one that leaves it.
• Give each configuration and package its own build-program output directory,
  target/.build-mcpp/out/<configuration>/<package> below the build's root,
  and record it as outDir in resolution.json. mcpp::out_dir() and
  MCPP_OUT_DIR change; ${mcpp.out_dir} does not.
• Write nothing at an action's outputs before the action runs. A generated
  translation unit enters the plan from its action's declaration; a generated
  module interface without .provides(...) is reported as degraded.
• Keep the managed toolchain's library path out of ninja's environment on
  Linux, so no shell ninja starts loads the toolchain's libc++. The managed
  tools find their libraries through their own RPATH; a compiler without one
  gets the path on the tools alone.
• Pin xlings 2026.10.10.2 and bootstrap from mcpp 2026.10.8.1.

Added

• Warn when --toolchain replaces a toolchain the manifest declares, naming
  both, the key and the file. The warning does not fail --strict.
• Report android in mcpp self env --format json. An Android host takes the
  default toolchain of GNU/Linux on its architecture; Android 10 or later is
  required.
• Show an xlings extraction that runs longer than 10 s and a long install hook
  as Installing lines while a toolchain is installed, and give the install
  hint by the failure's class (network, disk full, permission, damaged
  archive).
• Run Termux fresh-install jobs on the released archive: termux-docker on an
  arm64 runner and the Termux app sandbox on an Android 14 emulator.

Fixed

• Take a module unit's role from its module declaration and its language from
  its extension (#790). An implementation partition in a .cpp writes its BMI
  and is not rebuilt by every build; an interface unit in a .cpp is found by
  its importers under Clang. cl.exe compiles an implementation partition with
  /internalPartition.
• Regenerate an action's output that was removed while the build's log
  recorded the action (#778), and keep a profile's generated output from
  serving another profile.
• Find the Windows SDK where its installer recorded it (KitsRoot10) and under
  %ProgramFiles(x86)%/%ProgramFiles%, and vswhere.exe under
  %ProgramFiles(x86)%. Say which half of the MSVC ABI is missing, and where it
  was looked for, both on a first run that falls back to MinGW-w64 and when a
  specified MSVC-ABI toolchain is refused; a specified toolchain is never
  replaced.
• Resolve the shell an argv-launched command string runs in (/bin/sh, else
  /system/bin/sh, else $PREFIX/bin/sh).
• Report the first error of an xlings install, which is its cause, and the
  failure of a dependency's own address ahead of the compat spellings tried
  after it.
• List in mcpp index list the indices resolution searches on a workspace
  root and its members: [workspace.indices] and the root's own [indices].
• Run a build program of a workspace member once for a build and
  mcpp emit build-database: its output directory is beside its cache.

v2026.10.8.1

Changed

• Move the LLVM target line and macOS/Windows-with-MSVC defaults to 23.1.3.
  New Linux aarch64 installations select LLVM 23.1.3 and the native GNU target;
  Linux x86_64 retains GCC 16.1.0. Existing user defaults and explicit musl
  targets remain available. The ARM64 rollout depends on the coordinated
  xlings client and architecture-specific runtime resources.
• Use the native GNU manifest row when building mcpp and installing the
  toolchain for ARM64 consumer jobs. Centralize E2E toolchain version discovery
  and respect a custom MCPP_HOME.
• Search no system header directory of the host on a managed C library. clang
  carries -nostdlibinc on the native Linux rows, including through the driver
  configuration file regenerated after installation; GCC without a usable
  subos takes -isysroot <C library payload> in place of the sysroot recorded
  when it was built. A project that needs a host header writes the directory,
  for example cxxflags = ["-idirafter", "/usr/include"]; allow_host_libs
  concerns the link only. The std module and object caches of Linux clang
  builds are rebuilt once.
• Mark aarch64-linux-gnu preview until the released engine is consumed on
  a clean ARM64 host.

Fixed

• Install explicitly requested toolchains for graph-supplied targets even when
  the host payload matrix cannot serve the target. Preserve the refusal for
  engine-selected foreign payloads.
• Keep AArch64 host std modules and build programs on the same compiler-rt
  code-generation settings. Suppress the driver's automatic unwinder library
  (--unwindlib=none, on every architecture) when a self-contained ELF already
  links its static unwinder explicitly.
• Stop E2E package discovery from exporting GCC's reserved GCC_ROOT variable,
  which redirected managed Windows GCC helper lookup to the registry wrapper.
• Verify the native ARM64 openkal stack and indexed JSON serialization and
  parsing, hosted TLS, thread destruction and concurrent exception unwinding
  in the four-host cross-target matrix.
• Cover both xcode-27 E2E shards and exercise explicit toolchain installation
  with a cold registry. Restore historical measurements to their original
  environment and adapt the namespace fixture to libc++ 23.
• Give the note for a graph-supplied C library only when the C library is the
  graph's, on the full build and on the fast path; a native build on a managed
  C library carries -nostdlibinc as well.

Known limitations

• clang 23 does not support C++20 coroutines on i686-pc-windows-msvc: it no
  longer predefines __cpp_impl_coroutine there, so the MSVC STL's
  <coroutine> is empty. The C++23 std module (through <generator>) and code
  that uses coroutines fail on that target, and mcpp appends a note naming the
  cause: C++20, where import std and import std.compat build, or optionally
  llvm@22.1.8 for that target. mcpp does not define the macro (#786).