Generate a JSON package manifest to enable repology.org indexing

[gistrec]

Context

repology.org aggregates package versions across many C/C++ package managers (vcpkg, Conan, Homebrew, distro repos) so library authors and users can see where a library is published and at which versions.

xmake-repo is currently not indexed by repology. A community contributor (@luadebug) has an open PR adding xrepo fetch support: repology/repology-updater#1585. The PR is blocked, not on principle, but on three specific data gaps. The repology maintainer @AMDmi3 made it clear that parsing xmake.lua source directly is a non-starter ("We will not parse source code in any way") but accepts indexing from a structured external source if it exposes the following fields:

1. homepage must be exposed per package (currently dropped)
2. Repository URL must be distinguishable from download URL — no heuristics like .git suffix matching
3. URLs must be concrete — no $(version) interpolation, resolved against the latest version

Proposal

Have xmake-repo CI publish a small packages.json manifest at a stable URL (e.g. a gh-pages branch, or a Release asset). Repology can then ingest directly.

Suggested minimal schema (one entry per package, latest version only — repology doesn't need history):

{
  "generated_at": "2026-05-12T12:00:00Z",
  "packages": [
    {
      "name": "geo-utils-cpp",
      "version": "1.0.1",
      "description": "A tiny header-only C++17 latitude/longitude geometry library",
      "license": "Apache-2.0",
      "homepage": "https://github.com/gistrec/geo-utils-cpp",
      "repository_url": "https://github.com/gistrec/geo-utils-cpp",
      "download_url": "https://github.com/gistrec/geo-utils-cpp/archive/refs/tags/v1.0.1.tar.gz"
    }
  ]
}

Each field maps directly to an xmake.lua call (so generation is just sandboxed evaluation, which xmake already does on install):

Field	Source in xmake.lua
name	package directory name
version	latest add_versions(...) entry
description	set_description(...)
license	set_license(...)
homepage	set_homepage(...)
repository_url	first source URL recognised as git/https://github.com/... (known at generation time, no heuristic)
download_url	first archive URL from set_urls(...), with $(version) substituted by the latest version

A scripts/build_index.lua could iterate packages/**/xmake.lua and emit the JSON; a CI job runs it on every merge to master and commits to gh-pages (or uploads as a release artifact). Estimated effort: ~50-100 lines of Lua + a small workflow.

Why this is worth it for xmake-repo

• Library authors gain visibility — repology is the canonical "where is my package available" cross-index for C/C++.
• Users see at a glance that a library is published on both vcpkg and xmake-repo, which raises xrepo's profile.
• Unblocks an already-written PR (#1585) — no work needed on repology's side once the manifest exists.
• The lift is small and self-contained: an internal CI script + one published file.

Happy to help draft the generation script if there's interest.

[gistrec]

Opened a draft PR with a concrete implementation for review: #9967.

• scripts/build_index.lua — uses xmake's own loader (no source parsing); resolves $(version) placeholders; verified locally on dev (1952 packages, 0 unresolved URLs).
• .github/workflows/build-index.yml — publishes dist/packages.json to gh-pages on every push to master.

Open questions (schema, publish target, trigger frequency) in the PR description. Happy to iterate based on your feedback.

[luadebug]

Maybe it should be dev branch instead of master branch.

[AMDmi3]

• Version aliases are not handled, which leads to invalid versions and urls:

      "version": "home:1.2.10",
      "description": "The Advanced Linux Sound Architecture (ALSA) provides audio and MIDI functionality to the Linux operating system.",
      "download_url": "http://www.alsa-project.org/files/pub/lib/alsa-lib-home:1.2.10.tar.bz2",
      "repository_url": "https://github.com/alsa-project/alsa-lib",
      "homepage": "https://alsa-project.org/wiki/Main_Page",
      "license": "LGPL-2.1",
      "name": "alsa-lib"
    },

• If you provide data for repology, v should be stripped on the generation side. In fact it looks like v should be stripped in the scripts and moved to urls, consistently with other git tag prefixes.

• I'd expect only files in download_url, and verbatim .git urls in repository_url

      "download_url": "https://github.com/sekrit-twc/libp2p.git",
      "repository_url": "https://github.com/sekrit-twc/libp2p",

  Likely related, no download_url here:

    {
      "version": "v0.1.30",
      "description": "LibThai is a set of Thai language support routines",
      "download_url": "https://github.com/tlwg/libthai.git",
      "repository_url": "https://github.com/tlwg/libthai",
      "homepage": "https://github.com/tlwg/libthai",
      "license": "LGPL-2.1",
      "name": "libthai"
    },

  while there is

    add_urls("https://github.com/tlwg/libthai/releases/download/v$(version)/libthai-$(version).tar.xz", {
        version = function (version)
            return version:gsub("v", "")
    end})
    add_versions("v0.1.30", "ddba8b53dfe584c3253766030218a88825488a51a7deef041d096e715af64bdd")

• I'd also expect these urls to be an array. What are the semantics of multiple urls?

• Would be nice to include patches

• You sure you only want the latest version?

[AMDmi3]

A bunch of packages are also missing a version: aqt autotools cef cmake cuda curl diasdk fls-float-raylib gfortran glu glut glx gsl gspell gtk+4 houdini libc++ libcurl libsdl libsdl_gfx libsdl_image libsdl_mixer libsdl_net libsdl_ttf libudev libxnvctrl llvm matlab msmpi msys2 ndk nvtx opencv-mobile opengl openmp optix postgresql protoc qt5core qt5gui qt5network qt5webview qt5widgets qt6core qt6gui qt6network qt6qml qt6quick qt6widgets vulkansdk w64devkit

[gistrec]

@AMDmi3 thanks for the detailed review — going through your points.

A couple of examples seem to be fixed in the currently published index already: alsa-lib no longer has the home: prefix, and libthai now has the release tarball in download_url with the git URL in repository_url:

{
  "name": "libthai",
  "version": "0.1.30",
  "download_url": "https://github.com/tlwg/libthai/releases/download/v0.1.30/libthai-0.1.30.tar.xz",
  "repository_url": "https://github.com/tlwg/libthai.git",
  "homepage": "https://github.com/tlwg/libthai",
  "license": "LGPL-2.1"
}

So the alias-prefix stripping, leading-v stripping, and .git/tarball URL separation should now be live. Worth re-pulling the index if your tests were using an older snapshot.

For the remaining missing versions, I see three different cases:

1. Platform-conditional add_versions()

Packages like cuda, cef, aqt, msmpi, ndk, vulkansdk, qt5*/qt6*, llvm, postgresql, etc. define versions inside platform/host conditionals. The generator currently runs on Linux, so Windows/macOS-only branches never register versions. I checked whether the xmake loader can be told to "load as if on platform X" — {plat=...} option, XMAKE_HOST env, neither works; is_host() always returns the actual builder OS.

My default plan is to load packages once per synthetic platform by patching the platform predicates and then merge the collected versions. This is a bit more fragile than a CI matrix, but keeps the index generated in one job. If you strongly prefer a Linux/macOS/Windows CI matrix instead, I can switch to that.

2. set_base() alias packages

Packages like libsdl → libsdl2, gtk+4 → gtk4, qt5core → qt5lib, fls-float-raylib → raylib, etc. do not carry their own versions. I'll follow the base package and reuse its versions/URLs, similar to the existing scripts/packages.lua handling.

3. Pure find-system packages

Packages like glu, glut, glx, opengl, openmp, libc++, libudev, autotools, etc. have no add_urls() / add_versions() and are just wrappers around system packages. I plan to skip them from the manifest entirely, since there is no upstream version/download URL to report. Please let me know if Repology would prefer placeholder entries instead.

For the schema changes, my proposed defaults are:

• keep download_url for compatibility and add download_urls for mirrors/alternates;
• expose patches as repo-relative paths first, without extra metadata;
• keep only the latest version for now, unless Repology needs all historical versions.

If this shape works for you, I'll send a follow-up PR covering alias resolution, find-system skipping, platform-merged versions, and the schema changes, then run one final pass over the missing-version list.

[waruqi]

@gistrec I think we can now migrate the synchronization scripts to this repository: https://github.com/xmake-io/xmake-packages-index

[gistrec]

Opened #10355 covering the remaining review items.

@AMDmi3, status per your list:

• Missing versions — all 51 packages resolved: set_base aliases (curl, libsdl*, gtk+4, qt5*/qt6*, …) now inherit versions/urls/patches from their base package (and carry a "base" field so you can skip or bind them as you prefer); add_versionfiles packages (libcurl, ndk) go through the proper API; cmake/opencv-mobile get their dynamic sources initialized; host/arch-conditional packages (cuda, cef, aqt, w64devkit, llvm, …) are loaded under synthetic host/plat/arch profiles and merged. The 21 packages that are pure system/SDK wrappers with no upstream at all (opengl, glu, matlab, autotools, protoc, …) are now excluded from the manifest instead of appearing versionless — shout if you'd rather have them as placeholder entries.
• "I'd also expect these urls to be an array" — added download_urls (all mirrors for the latest version). download_url is kept for compatibility and is always its first entry. Semantics of multiple urls: alternate mirrors of the same archive.
• "Would be nice to include patches" — added patches: repo-relative paths (or verbatim URLs for remote patches) of the patches applied to the latest version.
• "You sure you only want the latest version?" — added versions: all known versions, ascending, same normalization as version.

After the PR is merged the published index at https://xmake-io.github.io/xmake-repo/repology_packages_index.json refreshes within the hour. I'll then ask to reopen repology/repology-updater#1594 (or open a fresh PR) with the parser updated for the new fields.

@waruqi re: moving the sync scripts to xmake-io/xmake-packages-index — happy to do that as a follow-up. My only concern is URL stability: the repology fetcher will point at the gh-pages URL above, so I'd suggest migrating the generator after repology starts consuming the index (or keeping a redirect/copy at the current URL). If you'd prefer the index to be published from xmake-packages-index from the start, let me know which public URL it should live at and I'll adapt both sides.

[waruqi]

If you'd prefer the index to be published from xmake-packages-index from the start, let me know which public URL it should live at and I'll adapt both sides.

you can add a new build_repology.lua script to generate it. https://packages.xmake.io/repology_packages_index.json

like this:

https://github.com/xmake-io/xmake-packages-index/blob/3bb0cee595a3d05b5a80e0b5a43d1b9dc0b633e9/build.sh#L159
https://github.com/xmake-io/xmake-packages-index/blob/main/indexer/build.lua