mcpp.toml

# Members are independent packages with their own mcpp.toml, referenced by
# path. Listed leaves-first, which is also dependency order:
#
#   libs      json, sha256, tinyhttps: self-contained, nothing of xlings
#   runtime   -> libs: cancellation, guard (confirmation), observe (journal)
#   platform  -> runtime: the OS boundary -- every system header and call
#   home      -> libs, platform: the home's format -- its layout version,
#                which clients understand it, the steps that bring an older
#                home forward, the classes a problem falls into
#   ui        -> platform: theme and i18n
#   cli       -> libs: the command-line model (a declared command tree;
#                validation, tiered help, completion), shared by xlings and luban
#   store     -> libs, platform: what keeps a payload alive (GC roots, the
#                retained ledger)
#   subos     -> libs, runtime, platform, store: the SubOS core
#   confine   -> subos: the sandbox implementations, their selector, the
#                platform matrix
#   carrier   -> subos: where a SubOS runs (local, wsl2, vz) and how this
#                xlings reaches it
#   image     -> platform: disk and disc image formats, written in-process
#   luban/*   -> modules: Luban OS -- system (stage-0), service (environments
#                and machines as operations), vm (a machine run here), cli (the
#                luban command; apps/luban is its binary); xlings never imports
#                them (tools/lint_layer_deps.sh)
#   testkit   -> libs: end-to-end test library (dev-dependency only)
#   apps/gui  the GUI binary's library half
#   apps/xdev the development tool (never linked into xlings)
#
# `apps/` holds what becomes a binary; `modules/` holds what gets linked into
# one, a package per responsibility (not per file). `src/` is what has not
# been separated yet -- core, cli, ui, runtime -- and shrinking it is the
# direction.
[workspace]
members = [
    "modules/libs",
    "modules/runtime",
    "modules/platform",
    "modules/home",
    "modules/i18n",
    "modules/ui",
    "modules/cli",
    "modules/subos",
    "modules/confine",
    "modules/carrier",
    "modules/image",
    "luban/os/system",
    "luban/os/compat",
    "luban/os/service",
    "luban/os/vm",
    "luban/os/cli",
    "luban/specs/opensal",
    "luban/specs/openhal",
    "luban/specs/openas",
    "luban/specs/opencaps",
    "luban/kits/imkit",
    "luban/kits/openhal-host",
    "luban/kits/tray",
    "luban/kits/opensal-wlr",
    "luban/xdesk/base",
    "luban/xdesk/layout",
    "luban/xdesk/compositor",
    "luban/os/window",
    "apps/luban",
    "apps/luban-os",
    "luban/xdesk/app",
    "modules/testkit",
    "apps/gui",
    "apps/xdev",
]

[package]
name = "xlings"
version = "2026.10.20.3"
description = "Universal package management infrastructure tool with SubOS isolation"
license = "Apache-2.0"
repo = "https://github.com/openxlings/xlings"

[build]
# modules/testkit/include holds xtest.hpp (the XTEST macro). Only test sources
# include it; it is here because test TUs are compiled with the root's flags.
include_dirs = ["modules/libs/src/json", "modules/testkit/include"]
# Minimum supported macOS for produced binaries (mcpp 0.0.50+ honors
# this; the MACOSX_DEPLOYMENT_TARGET env in CI/release remains as the
# second line of assurance and covers older bootstrap mcpp versions).
macos_deployment_target = "14.0"
cxxflags = ["-DLIBARCHIVE_STATIC", "-DUNICODE", "-D_UNICODE"]

# A UTF-8 activeCodePage application manifest (Windows 10 1903+; mcpp.toml
# reference: docs/04-mcpp-toml.md §2.15 in the mcpp repository). Only PE
# targets compile this section; Linux and macOS builds are unaffected,
# byte for byte. With the manifest present, std::filesystem::path::string()
# and the -A Win32 APIs operate in UTF-8 instead of the process's legacy
# ANSI code page, so xlings no longer raises an uncaught std::system_error
# during start-up when its working directory contains a character the ANSI
# code page cannot represent (mcpp#693). The shims xlings creates on
# Windows are hard links or file copies of xlings.exe (see create_shim in
# src/core/xself/init.cpp) -- of the xlings.exe that was the entry when they
# were made. An upgrade replaces the entry's file object, so a shim carries
# THIS manifest only once it has been re-pointed (`replace_entry_binary`) or
# hands off to the entry at startup (#615).
# longPathAware (design mcpp 2026-10-16 §14 X6): with the system's
# LongPathsEnabled, the wide file APIs take paths past MAX_PATH -- a store
# under a deep home no longer fails at 260 characters.
[resources]
files = ["docs/res/xlings.rc"]
# The .rc input scanner recognises the `MANIFEST` keyword but not the
# equivalent numeric resource type (`24`) used in docs/res/xlings.rc, so the
# manifest is declared here as well to make sure editing it relinks.
extra-inputs = ["docs/res/xlings.exe.manifest"]

[targets.xlings]
kind = "bin"
main = "src/main.cpp"

# The graphical frontend is its OWN binary, not another way for `xlings` to
# draw. Measured: static musl's dlopen is a stub, and GLFW/GL find X11,
# Wayland and the driver through dlopen -- so the release binary cannot open a
# window whatever it is built with. `required_features` makes it a silent skip
# there rather than a build failure, and `xlings install xlings-gui` is how a
# Linux user gets one (the graphics stack is already closed in the index).
[targets.xlings-gui]
kind = "bin"
main = "apps/gui/main.cpp"
required_features = ["gui"]

[features]
default = []
gui = []

[feature-deps.gui]
ui-gui = { path = "apps/gui" }

[toolchain]
default = "gcc@16.1.0"
# macOS 23.1.3, not 20.1.7: the macOS 27 SDK's .tbd stubs list an `arm64e.x1`
# architecture that the ld64.lld shipped before LLVM 23.1.3 cannot parse
# (llvm-project#222721, backported to release/23.x as ee66426), so every link
# against that SDK died with "could not load TAPI file ... malformed file"
# (mcpp#669). 23.1.3 is the first point release carrying the fix. Windows
# stays on 20.1.7: nothing there blocks on the SDK, and the bump is a
# separate decision for this repository's own release engineering.
macos = "llvm@23.1.3"
windows = "llvm@20.1.7"

# Same major as the dev toolchain on purpose. gcc 15.1.0-musl rejects a
# `std::views::transform` pipeline once its function body lives in a module
# implementation unit ("use of `operator|` before deduction of `auto`",
# catalog.cpp), while gcc 16.1.0 accepts it -- and the reverse has bitten this
# project too: `views::split | ranges::to` compiled under 15.1.0-musl and made a
# whole module fail with "Bad file data" under 16.1.0
# (.agents/docs/2026-08-06-subos-architecture-proposal.md). Range adaptors in
# modules are fragile in BOTH directions across these two versions, so the two
# targets now share one compiler major instead of trading one breakage for the
# other.
[target.x86_64-linux-musl]
toolchain = "gcc@16.1.0-musl"
linkage = "static"

# aarch64 (ARM64) static target — host-aware (native musl-gcc on ARM,
# cross aarch64-linux-musl-gcc on x86). linkage=static implied by -musl.
[target.aarch64-linux-musl]
linkage = "static"

[dependencies]
libs     = { path = "modules/libs" }
runtime  = { path = "modules/runtime" }
platform = { path = "modules/platform" }
home     = { path = "modules/home" }
i18n     = { path = "modules/i18n" }
ui       = { path = "modules/ui" }
cli      = { path = "modules/cli" }
subos    = { path = "modules/subos" }
confine  = { path = "modules/confine" }
carrier  = { path = "modules/carrier" }
image    = { path = "modules/image" }

[dependencies.compat]
ftxui      = "6.1.9"
libarchive = "3.8.7"

[dependencies.mcpplibs]
xpkg = { git = "https://github.com/openxlings/libxpkg.git", rev = "5523780abfedf1e1e06d8b42a077fd76a70f284e" }
cmdline = "0.0.2"
capi.lua = "0.0.3"

[dev-dependencies]
testkit = { path = "modules/testkit" }
# Tests drive Luban's own modules (stage-0, the luban command); the xlings
# binary itself never links them.
luban-system = { path = "luban/os/system" }
luban-cli    = { path = "luban/os/cli" }
luban-compat = { path = "luban/os/compat" }
opensal     = { path = "luban/specs/opensal" }
openhal     = { path = "luban/specs/openhal" }
openas      = { path = "luban/specs/openas" }
opencaps    = { path = "luban/specs/opencaps" }
openhal-host = { path = "luban/kits/openhal-host" }
opensal-wlr = { path = "luban/kits/opensal-wlr" }
xdesk-base = { path = "luban/xdesk/base" }
xdesk-layout = { path = "luban/xdesk/layout" }
tray       = { path = "luban/kits/tray" }

[dev-dependencies.compat]
gtest = "1.15.2"

# Sanitizer profile for CI (`mcpp test --profile asan`). Not a default: the
# instrumented build is several times slower and only the unit suite runs
# under it. Issue #433: a use-after-free reached three releases undetected
# because nothing ever ran the tests instrumented.
[profile.asan]
opt      = 1
debug    = true
cxxflags = ["-fsanitize=address,undefined", "-fno-omit-frame-pointer"]
ldflags  = ["-fsanitize=address,undefined"]