clib: a package manager for C that checks dependencies into your repository

The problem clib targets: C libraries scattered across the web

The README states the motivation directly: C libraries are scattered all over the web and discovery is relatively poor, and the footprint of those libraries is usually large and unfocused. clib's answer is a set of stand-alone micro libraries that a developer can install quickly without coupling to a large framework. The project describes itself as the lazy-man's copy/paste promoting smaller C utilities, which is a fair summary of the design: it automates fetching source files rather than managing a compiled artifact graph.

The intended user is someone writing C who wants a handful of small dependencies and does not want to adopt CMake FetchContent, Conan, or a distro package for each one. The README is explicit that the fetched files are meant to be checked into your repository, so end users and contributors do not need clib installed. That single decision shapes everything else about the tool.

How clib resolves and installs a package

There is no central server. The wiki listing of packages acts as the registry and populates the results returned by clib-search(1), according to the README. Installation is driven by a clib.json file in the target repository, which can list source files explicitly or provide an install command.

The README gives two shapes. A library manifest names the repo, a version, a license, and a src array of files. An executable manifest replaces src with an install string such as make install. When you run clib install, the tool fetches the named repository and either copies the listed sources or runs the install command. The Makefile confirms the binary set: clib, clib-install, clib-search, clib-init, clib-configure, clib-build, clib-update, clib-upgrade, and clib-uninstall are all built and installed into PREFIX/bin, which defaults to /usr/local. The executable variants mean the same operations are reachable without the dispatcher.

Because the source lands in your tree, the dependency graph is flat by construction. clib does not compile your dependency into a shared object and does not track what that dependency itself needs. The README does not describe transitive resolution, so a library whose own clib.json lists dependencies is a case the documentation does not cover.

Installing clib and installing your first package

The README states that clib expects libcurl to be installed and linkable. On Ubuntu the documented sequence installs libcurl4-gnutls-dev, clones the repository, builds, and installs to the prefix. The Makefile picks up curl-config for compiler and linker flags unless STATIC is defined, in which case it uses deps/curl/bin/curl-config.

# install libcurl
sudo apt-get install libcurl4-gnutls-dev -qq
# clone
git clone https://github.com/clibs/clib.git /tmp/clib && cd /tmp/clib
# build
make
# put on path
sudo make install

Other documented routes are brew install clib on Homebrew, sudo port install clib after sudo port selfupdate on MacPorts, and nix-env -i clib on Nix. Once the binary is on your PATH, clib --help prints the command list shown in the README.

To start a project, the README lists clib init as the command that starts a new project, which is what produces a clib.json. Installing dependencies is then a single call. The README's own example installs two libraries into ./deps:

clib install clibs/ms clibs/commander

A second example changes the output directory to ./src with the -o flag, and a third shows that names from the clibs organization can be shortened, so clib install ms file hash resolves to clibs/ms, clibs/file, and clibs/hash. Executables install the same way, for example clib install visionmedia/mon visionmedia/every visionmedia/watch. After the command finishes you should see the fetched sources or the installed executables in the chosen directory, and the manifest in your repository records what was requested.

What clib does not do: version solving, lockfiles, and rollback

The README documents a version field inside clib.json, but it does not document a lockfile, a resolution algorithm, or a rollback command. clib upgrade takes a version argument to upgrade clib itself, not your dependencies, and clib update refreshes installed packages. If a dependency's upstream repository moves or deletes a tag, nothing in the documented workflow pins the exact commit you previously fetched. The mitigation the project itself prescribes is committing the fetched files, which freezes the bytes in your history but also means every dependency update shows up as a source diff in review.

A second limitation is the registry. The README says the wiki listing acts as the registry. That means search quality depends on a page maintained by hand, and the package namespace is effectively GitHub's. There is no signing, no checksum verification, and no documented audit trail beyond the commit you make. For a project with a security review process, that is a real constraint rather than a detail.

A third is platform reach. The Makefile carries an EXE switch that appends .exe to every binary name, and the installation section lists Homebrew, MacPorts, Ubuntu, Fedora, and Nix. Windows is not covered by the documented install paths, so treat the .exe support as a build-system accommodation rather than a supported distribution channel.

clib compared with vendoring by hand and with CMake FetchContent

The closest alternative is what clib replaces: cloning a library into deps/ yourself and adding its sources to your build. That approach has no extra dependency, works offline once cloned, and needs no tool installed. Its cost is that every update is a manual clone, and there is no manifest describing what you pulled or why. clib adds exactly that manifest and a one-line install command, at the price of requiring libcurl and a clib binary on the machine doing the fetching.

CMake's FetchContent module solves the same fetch problem from inside the build system, and it resolves at configure time with a pinned commit or tag. The difference in approach matters: FetchContent keeps the dependency out of your source tree and ties fetching to the build, while clib deliberately puts the source in your tree and treats the build system as someone else's concern. If your project already uses CMake and you want the dependency graph expressed in CMakeLists.txt, FetchContent is the more natural fit. If your project uses a hand-written Makefile and you want the dependency to exist as ordinary files you can read and patch, clib matches that model better.

Maintenance, licence, and the cost of upgrading

The repository is not archived, and the last push was on 2026-07-18. The most recent release listed is 2.8.7 from 2024-06-27, with 2.8.5 in 2023 and 2.8.3 in 2023 before that. So the release cadence is slow, and the gap between the latest release and the latest push means fixes may live on master before they reach a tagged version. If you install via a package manager such as Homebrew, MacPorts, or Nix, you inherit that channel's update lag on top of the project's own.

The upgrade path for clib itself is clib upgrade, which the README documents as taking an optional version argument. Upgrading your dependencies is clib update. Neither is free: because the fetched source is committed, an update produces a diff you have to review, and the README does not document a way to see what changed upstream before applying it.

clib is MIT licensed, and the LICENSE file sits at the top level of the repository. Package manifests also carry a license field, as the README's term example shows with "license": "MIT". That field is metadata declared by the package author; it does not mean every package you install shares clib's licence. Check the license field of each clib.json you pull in. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt clib if you maintain a C project that already vendors its dependencies and you want a repeatable command for pulling small libraries from GitHub instead of copying files by hand. Do not adopt it if you need transitive dependency resolution, a lockfile, or reproducible builds across machines, because the documented workflow checks fetched source into your repository and the README does not describe version pinning beyond the version field in clib.json. Before committing to it, run clib init in a scratch directory, install one package, and read the generated clib.json and deps layout to confirm the result matches what your build expects.

Frequently asked questions

Official sources

1. clibs/clib on GitHub
2. Issues
3. License: MIT
4. README
5. Releases