Hi,

due to the nature of how the clibs are distributed, the amount and quality of documentation varies tremendously. To improve on that I wrote a tiny Python tool that uses Doxygen's XML output to create single-page documentation as well as multi-page documentation of a deps/ folder. You can find a work-in-progress output here. You will notice some problems:

1. Most projects won't be properly documented because they don't use Doxygen-style comments. However, one still can browse the API and function signatures in a nice, coherent way.
2. Some projects do not show any output. This is because their package.json lists source files being present in sub-directories (e.g. src) whereas they are not downloaded into these subdirectories but into the root directory. Doxygen then cannot find them.
3. structs and macros are not properly parsed/output yet.

Anyway, some notable examples of nice documentation are fs and ok.

Here is my question/issue: could you please fix number 2?

use https://github.com/clibs/debug for conditional debugging

This could be useful for uninstalling executables. It would require we cache some information about a clib when install though.

define dependencies in package.json:

{
  "denpendencies": {
    "buffer": "*",
    "readline": "*"
  }
}

How about this feature? and a malloc error when I run clib install just now.

Hi, clibs guys,

This is the link of my library: https://github.com/yorkie/readline
It do a tiny stuff like split('/n') in javascript, but I think it's needed to be added to the bundles of awesome packages.

I'm looking forward to your reply :p

possible enhancement: make some fields in the package description mandatory and add a command line option to check a json file if everything is correct and all values are in the description provided.
another enhancement: add a field in which environment the library is useable (windows AND linux, windows, linux, ....). if you include something like a linter for package descriptions you could test the values here as well to prevent that someone writes "win32" and another one "windows".

other possible fields for the package-file: 32bit, 64bit, c, c++, c++11

I really like the idea of describing libraries!

clib compiles just fine with gcc or clang with glib, but if you try to build with a different C99 compliant libc, such as musl, you get spammed with unknown type name errors which I believe indicate glibc dependence. I believe it should be a project goal of clib to be glib-independent to ensure greater portability across unix based systems.

$ CC=musl-gcc make
musl-gcc deps/case/case.c -c -o deps/case/case.o -std=c99 -Ideps -Wall -Wno-unused-function -U__STRICT_ANSI__
In file included from /usr/include/libio.h:32:0,
                 from /usr/include/stdio.h:74,
                 from deps/case/case.c:9:
/usr/include/libio.h:466:4: error: unknown type name ‘__gnuc_va_list’
    _IO_va_list, int *__restrict);
    ^
/usr/include/libio.h:468:5: error: unknown type name ‘__gnuc_va_list’
     _IO_va_list);
     ^
In file included from deps/case/case.c:9:0:
/usr/include/stdio.h:79:1: error: unknown type name ‘__gnuc_va_list’
 typedef _G_va_list va_list;
 ^
/usr/include/stdio.h:79:20: error: conflicting types for ‘va_list’
 typedef _G_va_list va_list;
                    ^
In file included from /usr/include/stdarg.h:10:0,
                 from /usr/include/libio.h:50,
                 from /usr/include/stdio.h:74,
                 from deps/case/case.c:9:
/usr/include/bits/alltypes.h:6:27: note: previous declaration of ‘va_list’ was here
 typedef __builtin_va_list va_list;
                           ^
In file included from /usr/include/libio.h:32:0,
                 from /usr/include/stdio.h:74,
                 from deps/case/case.c:9:
/usr/include/stdio.h:372:8: error: unknown type name ‘__gnuc_va_list’
        _G_va_list __arg);
        ^
/usr/include/stdio.h:377:54: error: unknown type name ‘__gnuc_va_list’
 extern int vprintf (const char *__restrict __format, _G_va_list __arg);
                                                      ^
/usr/include/stdio.h:380:8: error: unknown type name ‘__gnuc_va_list’
        _G_va_list __arg) __THROWNL;
        ^
/usr/include/stdio.h:391:42: error: unknown type name ‘__gnuc_va_list’
         const char *__restrict __format, _G_va_list __arg)
                                          ^
/usr/include/stdio.h:413:8: error: unknown type name ‘__gnuc_va_list’
        _G_va_list __arg)
        ^
/usr/include/stdio.h:472:7: error: unknown type name ‘__gnuc_va_list’
       _G_va_list __arg)
       ^
/usr/include/stdio.h:479:53: error: unknown type name ‘__gnuc_va_list’
 extern int vscanf (const char *__restrict __format, _G_va_list __arg)
                                                     ^
/usr/include/stdio.h:484:40: error: unknown type name ‘__gnuc_va_list’
       const char *__restrict __format, _G_va_list __arg)
                                        ^
In file included from /usr/include/features.h:371:0,
                 from /usr/include/stdio.h:27,
                 from deps/case/case.c:9:
/usr/include/stdio.h:496:37: error: unknown type name ‘__gnuc_va_list’
    const char *__restrict __format, _G_va_list __arg),
                                     ^
/usr/include/stdio.h:500:5: error: unknown type name ‘__gnuc_va_list’
     _G_va_list __arg), __isoc99_vscanf)
     ^
/usr/include/stdio.h:505:8: error: unknown type name ‘__gnuc_va_list’
        _G_va_list __arg), __isoc99_vsscanf)
        ^
make: *** [deps/case/case.o] Error 1

would be cool to have multiple sources to get package descriptions from, for example the public one you're maintaining and additional a private one with private libraries taken from some other source (file, usb-stick, ...)

having a clib-create command would be extremely useful when starting a new module, or converting an old one.

it'd act much like component-create, and do the following:

mkdir src
touch src/<name>.{c,h}
touch test.c
touch Makefile
touch package.json
touch Readme.md

thoughts?

See heapwolf/ldb@40bc332#commitcomment-6361235

I've probably configured something wrong here, but...

I've created a chrisdew/sds repo with a package.json file.

I can search it OK, but when I try to install, clib tries to get the files from clibc/sds rather than chrisdew/sds.

What have I done wrong?

$ clib search sds

  chrisdew/sds
  url: https://github.com/chrisdew/sds
  desc: Antirez's Simple Dynamic String library

$ clib install sds
       fetch : https://raw.github.com/clibs/sds/master/package.json
       error : unable to fetch https://raw.github.com/clibs/sds/master/package.json

Currently windows build is failing. Because deps/fs.c is older.

We're not on 1.2.3 quite yet...

utilize batch.c or something similar for lightweight thread support. because we've added windows support (i think), we'll need a windows threading alternative.

We need to document how the package.json format works.

Right now I want to create a package dependency for one package. I know this is possible when looking through: https://github.com/clibs/net/blob/master/package.json. However, someone cold to clib can't tell how to do this.

I think, at the very least, we need a link on the README that links to a wiki page that explains how the package.json file works.

Hey!

I stumbled upon this project through reddit, and I must say I'm quite happy someone decided to this. Browsing through the available packages, however, I noticed that there seems to be no consistency in naming, code style, comments, etc.

I would very much appreciate if there was some official clib/cpm code guidelines available through either the github wiki, or some other equally accessible platform. Would this be consistent with the vision and ambition of the clib/cpm project?

The primary incentives for forcing style and comments would be to help increase coherence and readability of code relying on clib/cpm packages, and could also be useful for generating coherent documentation through the clib/cpm tool suite.

obvs

I've been looking at documenting how to publish a project to clib, but I've come to realise we might need to first figure out a sustainable publishing process.

I think a sustainable publishing process has these two qualities:

• Maximises the user's ease of publishing packages to clib
• Minimises any intervention required by clib organisation members

Below are some suggestions for a publishing process.

a. User raises "publish" issues

1. User adds a package.json file to their repo
2. User submits an issue with the "publish" label to clib (includes repo details)
3. clibs organisation member will then add the project to wiki/packages

b. User becomes clibs organisation member

1. User sends email request for clibs organisation membership
2. clibs member grants membership
3. User adds package.json to their repo
4. User modifies wiki/packages

c. User raises pull requests against clibs/packages text file

1. User adds a package.json file to their repo
2. User clones clibs/packages (this is a repo that contains a single text file which is used instead of wiki/packages)
3. User adds a line in the text file for their project, submits pull request to clibs/packages
4. clibs organisation member merges pull request

d. User raises pull requests against clibs/packages package.json files

1. User clones clibs/packages (this is a repo that contains package.json files for each package instead of wiki/packages. Each package.json is given a file name based off its package name, eg. clibs-buffer.json)
2. User adds a package.json file for their package. The json file is actually named after the package, eg. clibs-buffer.json.
3. User submits pull request to clibs/packages
4. clibs organisation member merges pull request

Like in Ruby and Objective-C the convention is to use a file name without any extension which uses ruby syntax. Can a Clibfile be used to specify dependencies and the version number of the dependencies with a Clibfile.lock which holds the exact version of the library included if minor version updates are allowed.

Any objections, anyone?

I wrote this library that depends on clibs/list which is installs automatcially during make.

My question is how do I properly publish this and/or what instructions to I provide?

So lets say the user installs my lib via: clib install ee.c -o deps
Now in order to use it he'd actually have two options:

• cd deps/ee.c && make deps/list which would pull down list but then he'd still need to add the list related things like sources when building his lib
• cd deps/ee.c && make build/libee.a if he wants to link it locally

None of these seem like great options to me since then the user has to be aware of how to build the things he depends on, where ideally it should just be as easy as clib install x/y and done.

I noticed that mon even checks in all deps (instead of installing them).

So basically I'm trying to find a way (possibly via a postinstall) to prep the dependency at least to the point where the user does not have to be aware of all the nested dependencies and how to build them in order to use my lib.

Otherwise a lengthy explanation would have to be included with the readme on how to get started in which case just doing a make install would be easier although then we are back to installing libs globally (yikes).

When porting to C, I skipped this feature. It'd be nice to add it back:

$ clib install list user/{foo,bar}

It appears clib_package.c:clib_package_install only supports repositories hosted on GitHub. Users should have the option to install packages hosted on any Git server. What's the core team's opinion on the following syntax for package.json?

{
  "name": "my-package",
  "version": "0.1.0",
  "url": "https://github.com/me/my-package.git",
  "dependencies": {
    "my-friends-package": {
        "url": "https://[email protected]/my-friend/my-friends-package.git",
        "version": "0.1.0"
    }
  },
  "install": "make install"
}

If a package declares both a url and a repo key, the url key is preferred and a warning should be displayed. If only a repo key is declared, then it's business as usual and the repo is assumed to be hosted on GitHub.

If my-friends-package uses a hash, as it does above, the url and version keys are required. If it is declared using the current syntax of "my-friends-package": "0.1.0", then it behaves as it does now. Therefore these syntax changes are backwards compatible.

If there's interest in such a feature I'd love to work on it.

clib install stephenmathieson/rot132.c && echo fish and clib search rot132 && echo fish (intentionally failing commands) will both echo fish as the exit codes are not being set to non-zero on failure. This behaviour is generally expected for good Unix commands so it would be great if you could add this.

Thanks!

repo name suggests clib, but readme and binary suggest cpm

In C, memory leaks are major issues of a project.
To detect memory leaks and test it continuously, I suggest introducing a test with valgrind to detect memory leaks in CI.

Thoughts on something like this:

{
  "name": "whatever",
  "makefile": "path/to/makefile",
  "repo": ...
}

So we could:

mylib: libwhatever
  $(CC) ...

libwhatever:
  $(MAKE) -C deps/whatever
  ...

EDIT: gypfiles?

See https://gist.github.com/jwerle/58d4fcb72d339d9cc3db

An extra null pointer check is not needed in functions like the following.

• main
• matches

I try to use clib to install memcached like this clib install memcached/memcached, but it outputs an error:

error : unable to fetch https://raw.github.com/memcached/memcached/master/package.json

Does that mean if I want to install a repository, then the repository must provide a package.json file? If so, why not provide some common libraries in clib project itself?

thoughts on clib(1) only acting as an arbiter for sub commands?

imo, we should keep each command separate and let users only install what they need.

with clib@HEAD, the JSON:

{
  "name": "sophia-repl",
  "version": "0.0.0",
  "dependencies": {
    "linenoise": "*",
    "stephenmathieson/substr.c": "*",
    "stephenmathieson/emtter.c": "*"
  }
}

yields:

$ clib install
     warning : missing repo in package.json
       fetch : https://raw.github.com/clibs/linenoise/master/package.json
       fetch : https://raw.github.com/clibs/linenoise/master/linenoise.c
        save : ./deps/linenoise/linenoise.c
       fetch : https://raw.github.com/clibs/linenoise/master/linenoise.h
        save : ./deps/linenoise/linenoise.h
       fetch : https://raw.github.com/stephenmathieson/substr.c/master/package.json
       fetch : https://raw.github.com/stephenmathieson/substr.c/master/src/substr.c
        save : ./deps/substr/substr.c
       fetch : https://raw.github.com/stephenmathieson/substr.c/master/src/substr.h
        save : ./deps/substr/substr.h
       fetch : https://raw.github.com/stephenmathieson/str-copy.c/master/package.json
       fetch : https://raw.github.com/stephenmathieson/str-copy.c/master/src/str-copy.c
        save : ./deps/str-copy/str-copy.c
       fetch : https://raw.github.com/stephenmathieson/str-copy.c/master/src/str-copy.h
        save : ./deps/str-copy/str-copy.h
       fetch : https://raw.github.com/stephenmathieson/emtter.c/master/package.json
       error : unable to fetch https://raw.github.com/stephenmathieson/emtter.c/master/package.json
clib-install(32263,0x7fff7b798310) malloc: *** error for object 0x7f8303d00180: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

I encountered this problem when I tried to install the package jb55/anet.c.
The install wasn't successful because the program was trying to fetch this link:
https://github.com/jb55/anet/archive/master.tar.gz
where it should be:
https://github.com/jb55/anet.c/archive/master.tar.gz

It happens because the 'name' in the package.json file of this package is 'anet', whereas the repository name is 'anet.c'.

I checked and it looks like the problem could be solved by changing the way the link is formed in clib-install.c line 88, and it requires some other changes probably.

I would try to fix it myself but I'm not sure if it's the right thing and what other problems this change could introduce, so let me know what you think.

There are a decent number of little portable C libraries already available via CCAN. Perhaps someone can import those libraries, or come up with a way of indexing them? It would be a shame to ignore the work that has been done over the past several years: http://ccodearchive.net/list.html

See #29 and I have a plan to do 3 following stuffs for clibs:

• a network client library based on libuv and openssl, it provided a common API for net or tls, same for http and https.(most implemented by me)
• to be refactoring clibs/clib based on 1st plan.
• to be contributing to clibs/http based on 1st plan.

After that, clib is based on libuv, as @stephenmathieson said, it is so huge dependence, and do you have some suggestion for this?

/cc @clibs

github.com/component/component

to share them. we can pretty much copy/paste component's stuff

as we're rewriting in c, do we really care if cpm is taken in npm?

annoying to use node just for this

We need dox for the following:

• package.json grammar (dependencies, makefile, etc.)
• "publishing" a package
• requesting membership to the org

The install property in package.json doesn't exist. It needs to so clib can install itself. :)

We've been using clib(1) at our startup and it's been very helpful. However, there are two main things I'm wondering if we could do better at.

The first thing is namespaced packages. We use several C libraries for one of our services, the main one being ccv for most of our computer vision needs. The way we have our dependencies structured right now is with two directories: clib-deps/ and deps/. For packages with clib(1) support, we run clib install -o clib-deps blah/blah beep/boop, and all other packages, such as ccv, end up in deps/ (which is done manually). The reason we do this this way is, of course, because clib(1) installs are not namespaced, and we don't have a backend like the npm Registry to help out. So, I'm wondering, since we rely on GitHub as our equivalent (kinda) to the npm Registry (which I think is a good thing), can we make it so that clib(1) packages are namespaced based on the GitHub username/organization? I'm willing to make the commits to support this behavior if we can agree on it.

The second thing is pseudo packages. Because the majority of the libraries we use don't support clib(1), we have to manually manage them. I think we can fix this with what I'm calling "pseudo packages". A pseudo package would be nothing more than a repo with a package descriptor, where the package descriptor would just describe how to grab the real library. For example, this would allow me to just create a pseudo package for ccv and just pull it in using clib(1). However, in order to build a robust system for this, I think we would first need to work on #51 (clibs/clib-package#3).

I would really love to hear thoughts on these suggestions!

Thanks.

• Jonathan

where's the instructions for installing this on Ubuntu, Debian? I'm not using OS X so I obviously don't have brew.

make install 

fails unless libcurl-dev package is installed
ubuntu:

sudo apt-get install libcurl4-openssl-dev

I'm using list in a node module, which causes npm to randomly rename a gypfile I've added (see npm#4630). It seems anything with a package.json and a .gyp is subject to arbitrary renaming of files.

While this would be a drastic change, and the issue is a bit edge-casey, what are thoughts on renaming package.json to clib.json (or w/e)?