xmake-private-packages

Private Packages & Repository Distribution

This skill covers distributing C/C++ libraries as xmake packages — i.e. consumable via add_requires("mylib") in a downstream project. Three scenarios:

1. Local package — xmake package emits a directory of prebuilt binaries + a tiny xmake.lua repo you can share over NFS/file share.
2. Remote source package — a private git repo containing recipes that fetch source (usually from another private git repo) and build on demand.
3. Remote binary package — private git repo of recipes that download a pre-built tarball (no source leak, fast install).

All three reuse xmake's standard add_requires / add_packages integration on the consumer side — you just swap the repository URL.

1. Prepare the library project

-- 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.

2. Local package distribution

Produce the package

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.