Changelog
All notable changes to Alien::Xrepo will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
v1.0.7 - 2026-10-15
Fixed
- Limit each package to one registry refresh and one automatic retry per build tree. The counter is stored in checkpoint data so this limit is applied even if the build is resumed after a mid-stage failure.
- Checkpoints now record each stage as completed before persisting, so a resumed build does not repeat tasks that completed in a previous attempt.
v1.0.6 - 2026-10-14
Alpha runtime dependency diagnostic for FFI libraries. If, say libsdl3_ttf requires freetype, Alien::Xrepo will let you know.
It's... a work in progress.
Added
- Runtime dependency diagnostic for FFI libraries:
Alien::Xrepogainsruntime_deps,fetch_closure,scan_runtime_deps,loader_env_var, anddep_search_dirs.Alien::Xrepo::PackageInfogains thedepsandruntime_depsfields pluswith_runtime_deps.
Changed
Alien::Xrepo::Buildrecords each package's runtime dependencies so they ride into the snapshot and back out throughRuntime::package_infowithout a second scan. Also warns when a dependency isunresolved.- Require
Alien::Xmakev1.0.5
v1.0.5 - 2026-10-14
Added
Alien::Xrepo::Build::assert_installed, an opt-in all-or-nothing check a packaging caller runs afterrun(): it drops the just-written snapshot and dies listing every package that failed, so a dist with a broken package fails its build instead of being reported green.run()itself stays non-fatal so one failed package never hides the siblings that did install.Alien::Xrepo::Runtimesnapshot introspection:has_snapshot,snapshot_path, andsnapshot_errors, so a consumer's tests can tell a cold checkout (no snapshot) from a snapshot that was written but is incomplete (a failed build).
Changed
Alien::Xrepo::MBandAlien::Xrepo::MMnow callassert_installedafter the build, turning a partial or failed install into a build failure.
v1.0.4 - 2026-10-07
Fixed
- ExtUtils::Install installs files as readonly (mode 0444) so Xmake's templates (used by
xmake create, etc.) would copy readonly files into a project and then try to modify them which obviously does not work. I just copy them to the global xmake directory on first use and fix permissions. - In situations like prebuilt libs bundled in a single archive,
libpathused to resolve to whichever lib the filesystem happened to sort first. The runtime library now uses the package'slinks; falling back to the first lib when none match.
v1.0.3 - 2026-10-06
Added
systemrecipe option. Withsystem => 1a package is allowed to resolve from the system (Homebrew, apt, vcpkg, ...), which makesadd_extsources()in a package recipe usable again. Without it an install is a private build into its own store, as before.
Fixed
systeminstalls no longer automatically collapse into a source build.- A package reported with an install tree but no
libfilesis no longer mistaken for a header-only package.
v1.0.2 - 2026-10-04
- Make some of the flaky tests Author's tests. Their failure means very little, honestly, and could fail for a lot of reasons.
v1.0.1 - 2026-09-11
Added
Alien::Xrepo::MBandAlien::Xrepo::MM, generic Module::Build and ExtUtils::MakeMaker integrations for Alien distributions- Build engine
share_diroption: per-package installs land under<share>/<pkg>viainstalldir, and the snapshot records share-relative paths so an installed dist resolves packages after relocation to the site sharedir. - Example distributions demonstrating the new recipe shapes:
Exotic::SDL3installs multiple shared libraries for FFI consumers with one AlienExotic::Ninjademos a binary tool alienExotic::ZstandardandExotic::LsquicdemonstrateAlien::Xrepo::MBExotic::Raylib6example distribution on the usingAlien::Xrepo::MMExotic::SQLite3Exotic::Zlibdemos static library building forcc_lib_flagsconsumers like Inline::C or XSExotic::Vcpkg::zlibinstalls a lib from a 3rd party repo
- Package
versionpinning
v1.0.0 - 2026-09-07
Splitting this out of the Alien::Xmake dist and repo
Changed
- It exists? Check the Alien::Xmake changelog, I guess