[ccan] A few questions about ccan

[Tim Post]

On Tue, 2009-02-24 at 21:16 -0800, Stephen Cameron wrote:

> Or to put it another way, is ccan primarily yet-another-packaging-scheme?

The modules are packaged predictably, so surely its possible to write 10
different clients to grab and manage them.

I've been sketching out something written in C using sqlite to store
meta data so that when 500 modules appear, I can search for one and grab
it into any given source tree, or update them in place. No code yet,
just ideas.

Someone else might do one in perl, someone else python, who knows ..
someone may do something in emacs lisp. With stuff like SWIG getting so
popular who knows where it will go.

I asked about a client a while back ... it seems that its better to
package modules in a way that let anyone write a client. After that,
natural selection takes over.

> There are obviously a lot of libraries and such which can be had via "yum install
> xxx-devel" or "apt-get install xxx-devel" and source is typically available 
> through apt-get and RPM/yum as well. (though RPM/yum and apt-get are 
> obviously OS-specific).  Is the expectation that these sorts of things
> would be additionally packaged as ccan modules?

I think most people use ccan modules as drop ins. I asked about this and
Rusty is not setting a ceiling. The difference between library and
snippet is entirely subjective.

A good example might be this .. recently a limited regex module was
debated for creation (and inclusion). I would hope that an application
developer could detect a system having pcre prior to reverting to the
shipped ccan module. Numerous tools exist to do just that.

I think (Rusty, correct me if I'm wrong) if someone goes through the
trouble of making a lint agreeable module and uploads it with a test
suite.. its assumed that said person understands and can maintain the
code.

Following Linux, lguest, Xen and others, I know Rusty to hate winged
comments and excessive whitespace .. so you may get some nits when
uploading your stuff. I usually declare globals  like you have as
volatile and leave the rest up to gcc, but its your module :)

But, you researched (or wrote) it, you packaged it, its your baby. If I
use it and improve it, you'll get patches, which are up to you to accept
or reject.

How could one person keep track of 1500+ modules if/when ccan gets that
big? There's a format to follow, a lint to make happy and a test suite
to satisfy. Hopefully we can write Chuck Norris style "ccan lint facts"
after the next GSOC.

One can only hope that uploaders find a new maintainer if they need to
vanish. I suspect in 2 - 3 years time an "orphan" list will be on the
ccan page.

> Or is the long term view that the "comprehensive" aspect of ccan would some
> how provide an index of that sort of thing, rather than an additional copy 
> packaged a different way, the ccan way?

I think, if your smart enough to package a module .. common sense would
tell you if it really should be a dso submitted to various distros for
inclusion. 

That being said, any good library provides a static object .. so why the
hell not package it as a drop in implementation? Its up to the
application developer using it, not you, to manage bloat.

> Or is ccan more focused on smaller hunks of hackable C source, and less on
> "libraries"?

If you can define the difference between library and snippet and reach
an agreeable consensus you should be teaching or writing books, not
modules.

Cheers,
--Tim