mcpp.toml

# Members are independent packages with their own mcpp.toml, referenced by
# path. Listed leaves-first, which is also dependency order:
#
#   cancellation  leaf, std only
#   platform      -> cancellation      (81 of 211 TUs import it)
#   theme         leaf, std + the JSON header
#   apps/gui      the GUI binary's library half
#
# `apps/` holds what becomes a binary; `modules/` holds what gets linked into
# one. `src/` is what has not been separated yet -- core, cli, ui, runtime --
# and shrinking it is the direction.
#
# The vendored units moved too (json wraps nlohmann's header, tinyhttps wraps
# mcpplibs'): a module this project builds and exports is a module of this
# project, whoever wrote the code inside. Keeping them under `src/libs` while
# `modules/` existed meant two names for one idea, and `libs/` vs `src/libs/`
# already read as the same thing.
[workspace]
members = [
    "modules/json",
    "modules/sha256",
    "modules/cancellation",
    "modules/platform",
    "modules/i18n",
    "modules/tinyhttps",
    "modules/theme",
    "apps/gui",
]

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

[build]
include_dirs = ["modules/json/src/json"]
# 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).
[resources]
files = ["res/xlings.rc"]
# The .rc input scanner recognises the `MANIFEST` keyword but not the
# equivalent numeric resource type (`24`) used in res/xlings.rc, so the
# manifest is declared here as well to make sure editing it relinks.
extra-inputs = ["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 = "llvm@20.1.7"
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]
theme        = { path = "modules/theme" }
platform     = { path = "modules/platform" }
cancellation = { path = "modules/cancellation" }
i18n         = { path = "modules/i18n" }
json         = { path = "modules/json" }
sha256       = { path = "modules/sha256" }
# Named `xhttp` here to avoid colliding with `mcpplibs.tinyhttps`, which this
# member wraps. mcpp resolves dependency names in one namespace, so a member
# that wraps a registry package cannot share its bare name.
xhttp        = { path = "modules/tinyhttps" }

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

[dependencies.mcpplibs]
cmdline = "0.0.2"
xpkg = "0.0.60"
capi.lua = "0.0.3"

[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"]