-
Notifications
You must be signed in to change notification settings - Fork 245
Explanation of clib.json
clib.json files contain a single JSON dictionary with the following keys:
Note: clib.json might be named as package.json in older repos, but now it's strongly discouraged to do so.
The name of the package. Should be lowercase and match the regular expression /^[0-9a-z-_]+$/
.
The semantic version number of the package. This number should also be a git tag. For example, str-copy is at version 0.0.3
and has a tag matching that version (https://github.com/stephenmathieson/str-copy.c/tree/0.0.3).
An array of source files that make up the implementation of your package. In the case of str-copy
, this is:
{
"src": [
"src/str-copy.c",
"src/str-copy.h"
]
}
A dictionary of packages and their versions. Each entry represents a package dependency. A dependency must be a clib package.
Dependencies are specified in the following format:
"{github user}/{dependency name}": "version number"
Where "version number" may either be a git tag, branch or "*"
. When "*"
is specified, the most recent version will be used (e.g. the "master" branch).
For example, if your package was using version 0.0.3 of str-copy you would specify the dependency as:
{
"dependencies": {
"stephenmathieson/str-copy.c": "0.0.3"
}
}
You may specify any number of dependencies.
Development dependencies are for testing and development purposes.
This follows the same format as "dependencies"
, but will only be installed with $ clib install --dev
. This should include packages like:
{
"development": {
"stephenmathieson/describe.h": "*"
}
}
or
{
"development": {
"jwerle/libok": "*"
}
}
The GitHub slug for your package. This is generally {github username}/{package name}
, but may be different. For example, str-copy
's repo is stephenmathieson/str-copy.c
:
{
"repo": "stephenmathieson/str-copy.c"
}
A short-and-sweet description of your package. For example, str-copy's description is:
{
"description": "Copy a string"
}
An array of keywords which describe your package. This is currently not used, but when we move to a more sophisticated search, will be extremely helpful.
The license your package is released under. MIT is recommended.
Your package's Makefile. If your package requires a non-standard build process, it may be helpful to ship it with a Makefile. This way, packages using it as a dependency might include the following in their Makefile:
deps/your-package/your-package.o:
$(MAKE) -C deps/your-package
Your package's install script. This is typically make install
, but can be any executable (for example, ./install.sh
). The script should build your package and add it to $PATH
.
NOTE: This is for executables and libraries only. Defining an install
key will change the behaviour of clib-install(1)
-- your package's sources will not be installed to ./deps
.
Used by clib uninstall
, here you can define a script (defaults to make uninstall
) to uninstall your executable package. This is expected to remove your package from $PATH
and uninstall anything related.