From xmake-skills
Packages C/C++ libraries as private xmake packages and sets up local/git repositories for source or binary distribution within a team. Consumed via add_repositories + add_requires.
How this skill is triggered — by the user, by Claude, or both
Slash command
/xmake-skills:xmake-private-packagesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill covers distributing C/C++ libraries as xmake **packages** — i.e. consumable via `add_requires("mylib")` in a downstream project. Three scenarios:
This skill covers distributing C/C++ libraries as xmake packages — i.e. consumable via add_requires("mylib") in a downstream project. Three scenarios:
xmake package emits a directory of prebuilt binaries + a tiny xmake.lua repo you can share over NFS/file share.All three reuse xmake's standard add_requires / add_packages integration on the consumer side — you just swap the repository URL.
-- library project: xmake.lua
add_rules("mode.debug", "mode.release")
target("foo")
set_kind("static") -- or "shared"
set_version("1.0.0")
add_files("src/*.cpp")
add_headerfiles("src/foo.h") -- install to include/foo.h
add_headerfiles("src/foo_private.h", {prefixdir = "foo/internal"})
add_includedirs("include", {public = true}) -- expose to consumers
Key points:
add_headerfiles(...) marks headers for installation. prefixdir adds a subdirectory under include/.add_includedirs(..., {public = true}) is what makes downstream targets actually see the headers.set_version here flows into the package metadata.Run inside the library project root:
xmake package # local package (default)
# equivalent:
xmake package -f local
Output:
build/packages/
└── f/
└── foo/
├── macosx/x86_64/release/
│ ├── include/foo.h
│ └── lib/libfoo.a
└── xmake.lua # the generated recipe
build/packages/ is already a valid xmake package repository. You can copy it anywhere — shared drive, S3, local tarball — and consume it.
In another project's xmake.lua:
-- point at the local package tree
add_repositories("local-repo /nfs/shared/foo-packages")
add_requires("foo")
target("bar")
set_kind("binary")
add_files("src/*.cpp")
add_packages("foo")
add_repositories("<name> <path-or-url>") registers a repo. Xmake searches every registered repo for foo and uses the first match.
Benefits of local packages:
xmake package on each target platform and merge the trees.xmake package -f remote
This creates packages/f/foo/xmake.lua you can edit into a proper recipe.
-- packages/f/foo/xmake.lua
package("foo")
set_description("The foo library")
set_license("Apache-2.0")
add_urls("[email protected]:mycompany/foo.git")
add_versions("1.0.0", "<commit-sha-or-tag>")
on_install(function (package)
local configs = {}
if package:config("shared") then
configs.kind = "shared"
end
import("package.tools.xmake").install(package, configs)
end)
on_test(function (package)
assert(package:has_cxxfuncs("foo_init", {includes = "foo.h"}))
end)
package_end()
The recipe lives in its own my-repo git repo alongside any other recipes:
my-repo/
└── packages/
├── f/
│ └── foo/
│ └── xmake.lua
└── b/
└── bar/
└── xmake.lua
If you don't want consumers to see source or recompile:
package("foo")
set_description("The foo library (binary)")
-- a server hosting pre-built tarballs
add_urls("https://dist.example.com/foo/foo-$(version).tar.gz")
add_versions("1.0.0", "<sha256>")
on_install(function (package)
-- the tarball already contains include/ and lib/
os.cp("include", package:installdir())
os.cp("lib", package:installdir())
end)
on_test(function (package)
assert(package:has_cxxfuncs("foo_init", {includes = "foo.h"}))
end)
package_end()
Upload the tarball (produced by xmake package, xmake pack -f targz, or any other tool) to a server; the recipe pulls it by URL.
add_repositories("my-repo [email protected]:mycompany/my-repo.git")
add_requires("foo 1.0.0")
target("app")
add_files("src/*.cpp")
add_packages("foo")
First build clones the recipe repo into ~/.xmake/repositories/my-repo, then installs the package per the recipe.
For a one-off private package used only within a single project, keep the repo inside the project itself:
myproject/
├── packages/
│ └── f/
│ └── foo/
│ └── xmake.lua
├── src/
│ └── main.cpp
└── xmake.lua
-- myproject/xmake.lua
add_repositories("project-local packages") -- relative path
add_requires("foo")
target("myproject")
add_files("src/*.cpp")
add_packages("foo")
No external git, no shared tree — the recipe lives next to the code.
Add/remove global repo registrations:
xrepo add-repo mycompany [email protected]:mycompany/my-repo.git
xrepo rm-repo mycompany
xrepo list-repo
xrepo update-repo # pull latest recipes
Once globally registered, any project can add_requires("foo") without its own add_repositories line.
Use xmake-repo-testing's workflow inside your private repo:
cd my-repo
xmake l scripts/test.lua -vD --shallow foo
Catches recipe bugs before consumers hit them. See the xmake-repo-testing skill.
For pure C++20 module libraries, set moduleonly so xmake skips traditional linking:
-- library project
target("foo")
set_kind("moduleonly")
add_files("src/*.mpp")
-- recipe
package("foo")
set_kind("library", {moduleonly = true})
set_sourcedir(path.join(os.scriptdir(), "src"))
on_install(function (package)
import("package.tools.xmake").install(package, {})
end)
Consumer:
add_requires("foo")
target("app")
set_languages("c++20")
set_policy("build.c++.modules", true)
add_packages("foo")
See xmake-cxx-modules for the build side.
add_headerfiles. Libraries without declared header files install only binaries — consumers get link errors because the include path is missing.add_includedirs private. Without {public = true}, downstream targets don't see the include path even after add_packages("foo").add_repositories deliberately.add_requires("foo") gets whatever version the recipe's add_versions lists last. Pin with "foo 1.0.0" when the consumer needs determinism.xrepo update-repo before debugging "why isn't my new recipe showing up?".add_urls conditionally or multiple add_versions with arch filters.git@... need SSH keys in CI. Use HTTPS with a token or pre-clone ~/.xmake/repositories/ in CI setup.xmake-xpackxmake l scripts/test.lua) → xmake-repo-testingxmake-cxx-modulesxmake-packagesxrepo-clinpx claudepluginhub xmake-io/xmake-skills --plugin xmake-skillsInstalls, inspects, and exports C/C++ packages via xrepo, xmake's standalone package manager. Covers package search, install, fetch, repository management, and virtual environments.
Guides developers to wrap C++ libraries like libsodium, FFTW, OpenCV as reusable cpp.js packages installable via pnpm add, using scaffold script, CMake builds, and upstream versioning.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.