[ccan] Module dependency graph

[Adam Kennedy]

A framework is generally responsible for an area from the outside
inwards, it takes total control of an area and lets you play inside
those walls.

A CXAN may contain frameworks, but more typically it's going to supply
libraries. Pieces of functionality to fit inside your thing rather
than the other way around.

That some of these libraries themselves depend on other libraries is a
major positive in the long run. This is particularly the case if weird
fixes and special cases need to be solved for different and unusual
platforms and compilers.

The Perl Padre ide is a single package with around 100 recursive
dependencies, and works transparently across Windows, Linux and Mac
because it can not only have platform adaptive code in those 100
dependencies, but because the dependency graph itself can adapt.

There are some packages that are only a dependency on Windows that are
different to the dependencies you get on OS X or Linux.

If tdb has a dependency on foo, and you want the tdb.tar.gz as a
single monolith, then that should be an artifact of the toolchain or
the downstream packaging. It's available for use in that manner, but
it's not the way you store the master versions of the code.

That said, in the last few years the CPAN has accumulated a set of
Foo::Tiny packages. These have occurred in situations where the
"right" way to solve a problem required a lot of code and dependencies
to the point of annoyance, and there's a demand for cut down limited
alternatives with no dependencies that are easier to work with.

Adam K

On 17 January 2011 18:54, Joseph Adams <joeyadams3.14159 at gmail.com> wrote:
> I wrote a little Perl script for producing a graph of CCAN module
> dependencies with Graphviz.  Except for a little tweak needed to get
> the tools/ccan_depends --compile flag to work, the attached patch
> simply drops the script in the tools directory.  I didn't add any
> makefile magic.
>
> Usage (requires Graphviz; will take several seconds):
>
> tools/module-dep-graph.pl | dot -Tpng > out.png && xdg-open out.png
>
> Result:
>
> http://tinyurl.com/6jk4cbo
>
> Better yet, use the Graphviz tred (transitive reduction) tool to
> remove redundant edges (such as wwviaudio -> libvorbis):
>
> tools/module-dep-graph.pl | tred | dot -Tpng > out.png && xdg-open out.png
>
> Result:
>
> http://tinyurl.com/64s9r9d
>
> The second picture is much easier to understand.
>
> Looking at the graph begs the question: should CCAN be a collection of
> snippets that are easy to use in isolation?  Or should it be a
> framework, as the dependency graph suggests it currently is?  Although
> the former would be convenient for users, it would lead to maintenance
> difficulties (imagine having to fix a bug in multiple copies of ilog).
>
> _______________________________________________
> ccan mailing list
> ccan at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/ccan
>
>