# xmake-repo: the package definitions behind the xmake ecosystem

> xmake-repo is not a library but a repository of package definitions and project templates for xmake, where each package is a xmake.lua file describing URLs, versions, dependencies and build steps. Its real work happens in the pull request review pipeline, and the documentation leans on screenshots rather than text.

**xmake-io/xmake-repo** — 📦 An official xmake package repository 

- Repository: https://github.com/xmake-io/xmake-repo
- Website: https://packages.xmake.io
- Stars: 941 · Forks: 560
- Language: Xmake
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/xmake-io-xmake-repo

## This repository holds definitions, not source code

The first thing to understand about xmake-repo is that it is a data repository rather than a program. Nothing here compiles; the repository holds the xmake.lua files that describe packages to the xmake runtime, one file per package, laid out in directories named by first letter, so a package called zlib lives at packages/z/zlib/xmake.lua. The project also calls itself a project templates collection, and the templates directory holds the material behind xmake create.

That shape has consequences. A package definition is a small Lua program that says where the source archives are, which versions exist and what their checksums are, which other packages are needed, and how to build and test the thing. When a user adds a dependency to their project, xmake consults this repository, finds the matching definition and executes the recipe. The code that actually gets built is upstream code, fetched from the URLs in the recipe, and the recipe is what decides which platform, architecture, static or shared build, and build tool are used.

So the value of this repository is entirely in the quality and coverage of those recipes, and the maintenance of it is a matter of keeping them accurate as upstream projects move.

## A package recipe is a Lua script with a fixed set of calls

The generated example for libpng, which the documentation shows in full, is the clearest description of the format. It names the package, sets a homepage and a description, and then lists two source URLs, an archive for a release tag and a git repository. The versions call pairs a version string with a checksum, so the recipe is what makes a download verifiable rather than trusted. Dependencies are declared with add_deps, and the build itself is a function passed to on_install.

The install function receives the package object and can read the configuration it is being built for. The example switches the CMake build type between Debug and Release based on package:debug(), and turns shared libraries on or off based on package:config("shared"), then calls into the CMake helper of the package tooling to perform the install. The test function, registered with on_test, asserts that the built library exposes a given C function with a given header, which is a real check of the artifact rather than a check that the build did not fail.

The interesting part for a maintainer is that these are ordinary Lua functions. A recipe can therefore do anything a package author can express in Lua, including reading the environment and inspecting the target, and that is what makes platform-specific behaviour possible without changing the format.

## Packages are added by pull request to the dev branch

The contribution path is stated in one line: write a xmake.lua for the new package in packages/x/xxx/xmake.lua and push a pull request to the dev branch. The default branch of the repository is dev, and the CI badges at the top of the README cover Windows, Linux, macOS and Android, so a package that builds on one platform and not another is caught before it lands. The repository also carries a CONTRIBUTING.md file and a NOTICE.md file alongside the Apache-2.0 LICENSE.md.

There is a helper for the common case of an existing project on GitHub. It needs the gh command line tool installed, and a login step first.

```console
$ gh auth login
```

After that, a single command generates a package configuration file for the repository, using the package address on GitHub.

```console
$ xmake l scripts/new.lua github:glennrp/libpng
```

The generated file is not finished work. It starts with the name, homepage and description, and the URLs and versions still have to be filled in by the contributor, and the install function has to reflect how that project is really built. The generator removes the mechanical part of the work and leaves the part that needs a human, which is the right division of labour for a repository maintained by review rather than by generation.

## Testing a package locally before it is submitted

A repository of recipes needs a way to try a recipe out before it lands, and the scripts directory provides it. The test script takes a package name and a set of switches that mirror the dimensions a recipe can vary on.

```console
$ xmake l scripts/test.lua --shallow -vD zlib
$ xmake l scripts/test.lua --shallow -vD -p iphoneos zlib
$ xmake l scripts/test.lua --shallow -vD -k shared -m debug zlib
$ xmake l scripts/test.lua --shallow -vD --runtimes=MD zlib
```

The platform switch, shown with the iphoneos example, builds for a target other than the host. The shared and debug switches control the link type and the build type, which matters because a package that compiles fine as a static release library can fail as a shared debug build, and the two cases exercise different parts of a recipe. The runtimes switch selects which standard library runtime the target uses, which is a distinction that matters for Apple platforms in particular.

The shallow option suggests that the script does not need the full dependency tree for the check, and the verbose flags are for watching the build. Running these four shapes locally before opening a pull request is what keeps a recipe from landing with a platform condition nobody exercised.

## Project templates cover the first minutes of a new project

The second half of the repository is a set of project templates for xmake create, stored in the templates directory. The documentation gives one command as the example.

```console
$ xmake create -l c++ -t console myproject
```

The language and the type are chosen with flags, so the same generator covers a console project in C++ and other combinations, and the result is a project directory named on the command line. The point of shipping templates inside the package repository rather than in the xmake tool itself is that templates are versioned content: they can be corrected, extended and reviewed through the same pull request process, and they are picked up by the tool from the repository rather than compiled into it.

For a team standardising on xmake, that is a quiet but real benefit. A template can carry the compiler flags, the toolchain assumptions and the directory layout everyone agrees on, and distributing it through a pull request to a public repository means the standard itself is reviewable.

## xrepo is the client that turns these recipes into installed packages

The repository is not consumed only by xmake projects. The documentation introduces xrepo as a cross-platform C and C++ package manager based on xmake, which is built on the runtime xmake provides but is described as a complete and independent package management program. The comparison the project makes is with vcpkg and homebrew, and the claim is that xrepo can provide C and C++ packages for more platforms and architectures at the same time.

The difference in approach from those two tools is worth being precise about, because the claim is about coverage rather than about convenience. vcpkg and homebrew each ship packages built for the platform they run on, so a binary for one target has to be built on or for that target. A recipe-based repository can carry the build instructions for every target, so the same recipe can be executed for a phone, a desktop, a server or an embedded board on a single machine, and the platform conditions in the recipe decide what is possible. The price is that the build happens on the user's machine rather than being prebuilt and downloaded, so the result depends on the local toolchain.

This repository is where those recipes live, which makes it the substrate under both xmake projects and xrepo installs.

## The documentation is mostly screenshots, and the releases list is empty

Two gaps are worth naming before anyone adopts this as a dependency source. The first is the documentation itself. The sections that introduce package dependencies and package management are illustrated with images, one for adding a requirement and one for the package management screen, so the actual commands and configuration keys are not in the text a reader or a tool can index. The text that is there links out to the xmake documentation pages, which is where the real instructions live, and the xmake repository and the project homepage are the other two pointers. In other words, this repository is a data source with a thin textual guide, and anyone who wants to know exactly what add_require accepts has to leave the repository and read the tool's documentation.

The second gap is versioning. The repository has no GitHub releases, so there is no tagged version of the package collection to pin. The default branch is dev, and the last push was on 2026-10-20, so the content changes continuously. For a repository of recipes that is arguably correct, since you want the newest recipe for the version of a library you are building against, but it means the state of a package can change under you without any release note announcing it. A project that needs reproducible builds has to record which package versions it pinned in its own xmake.lua, because the repository itself offers nothing to pin to.

## Conclusion

Adopt xmake-repo when you build C and C++ projects with xmake and want dependencies resolved from a curated, cross-platform set rather than from a system package manager, and keep away from it if your build needs a package that has not been submitted yet or if you need per-package upstream support guarantees, since the project publishes no releases and the packages track upstream tags at the version the maintainer wrote. Before you depend on a specific package, read its xmake.lua to see which URLs, checksums, build system and platform conditions it declares, and check that the dev branch default has not moved the version you rely on.

## FAQ

### How do I add a package to the xmake package repository?

Write a xmake.lua for the package in packages/x/xxx/xmake.lua and push a pull request to the dev branch. The dev branch is the default branch, and CI runs for Windows, Linux, macOS and Android.

### How do I generate an xmake package definition for a GitHub project?

Install the gh command line tool and log in with gh auth login, then run xmake l scripts/new.lua github:glennrp/libpng to generate a package configuration file for that repository. The versions, URLs and install function still need to be filled in by hand.

### How can I test an xmake package recipe before submitting it?

Run the test script in the scripts directory, for example xmake l scripts/test.lua --shallow -vD zlib. Switches exist for the target platform, for shared or static builds, for debug or release, and for the runtime used by the target.

### What is the difference between xmake-repo and xrepo?

xmake-repo is the repository of package definitions and project templates. xrepo is the separate command line package manager built on the xmake runtime that installs those packages, and it is described as a complete and independent program rather than part of xmake itself.

### What licence does the xmake package repository use?

Apache-2.0, with the licence text in a LICENSE.md file at the repository root, alongside a NOTICE.md file and a CONTRIBUTING.md file.

## Sources

- [Issues](https://github.com/xmake-io/xmake-repo/issues)
- [License: Apache-2.0](https://github.com/xmake-io/xmake-repo/blob/dev/LICENSE)
- [Project website](https://packages.xmake.io)
- [README](https://github.com/xmake-io/xmake-repo/blob/dev/README.md)
- [xmake-io/xmake-repo on GitHub](https://github.com/xmake-io/xmake-repo)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xmake-io-xmake-repo