mcpp.toml

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

[build]
include_dirs = ["src/libs/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"]

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

[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]
ftxui = "6.1.9"

[dependencies.compat]
libarchive = "3.8.7"

[dependencies.mcpplibs]
cmdline = "0.0.2"
xpkg = "0.0.57"
tinyhttps = "0.2.9"
capi.lua = "0.0.3"

[dev-dependencies]
gtest = "1.15.2"