[PD] some notes for cyclone devs / maintainers

[katja]

Independent from the question who will contribute to cyclone in the
future and whose repository will be considered upstream I'd like to
share a few practical remarks on the build systems. In the old days I
would have sent this to pd-dev list but that may not be seen by
everyone involved now. A conversation can be redirected later.

Just like a library of books is more than a shelf with someone's
favorites, cyclone is more than a collection of Pd classes. For the
user it serves as a bridge between Pd and MaxMSP, but under the hood
it has consistency too, in the form of a specific framework. Pd users
don't need to know about hammer, sickle etc. as an interface to Pd,
but cyclone maintainers can't ignore it.

When Fred Jan started fixing bugs in cyclone, the code was embedded in
the programming structure of miXed, together with other libraries and
the shared framework. I got involved a bit later, with the
self-imposed task to develop a generalized build method for Pd
libraries that could support a complex source tree layout like
cyclone's. Since other libraries in miXed were essentially
unmaintained, with the exception of pddp which was forked inside
Pd-X's source tree earlier, I figured that cyclone's chances for
future maintenance would be best if it could be compiled with a build
system not relying on Pd-X or miXed as a set of libraries.

Cyclone's build system had over the years grown into an impenetrable
web of makefiles in miXed and Pd-X's library root dir. In the time
when Krzysztof Czaja started miXed, gnu make wasn't so '''advanced'''
as nowadays and he used some nifty tricks to design an expandable
build system, which in the end wasn't so expandable because no one
else could understand the tricks.

Today we have slightly more options for meta programming in gnu make,
notably the 'eval' function. The newly developed build method for
cyclone uses Makefile.pdlibbuilder, a generalized helper makefile for
Pd libraries big or small. Of course this helper makefile uses nifty
tricks too which aren't understood by everyone. But the calling
library makefile is transparent. And easily expandable.

An early version of the new build method was committed to SVN. When
IOhannes facilitated decentralization of Pd-extended with svn>git
conversion for all libraries, Fred Jan took cyclone to github for
continued maintenance. Technically speaking it is a fork, and
effectively it got split off from miXed. We've been considerate with
the structure and underlying framework though, conserving as many
pieces of the puzzle as could be put  together. Fred Jan reanimated a
part of cyclone that was lost to oblivion for a some years (nettles).
The makefile gives insight how class files per category relate to
dependencies in hammer, sickle etc.

Of course it is technically possible to add new classes which don't
use the framework functions. There are suggestions to start a new
library for new classes which follow a different code structure.
Indeed a split between classes using the framework and classes not
using it could simplify development. You can have independent
repositories, test / release cycles, and support. Cloning MaxMSP is
ambitious enough to justify division into sub projects. However if the
outcome of the discussion is that all must go in one cyclone lib, you
could at least organize source tree and build system in such a way
that dependencies between categories of classes and underlying
framework remain transparent. The build system could be split
according to categories of classes so devs can work in relative
isolation inbetween releases.

I'm not planning to participate in cyclone development myself, since
Makefile.pdlibbuilder is a big enough project for me to maintain,
apart from my personal Pd work. It is now unknown if cyclone will be
maintained as an individual library in its own repository or in a
larger context like Pd-L2Ork where it is still embedded in miXed. In
any case, here's my recommendation: make use of the new build
approach, because dealing with the old kludge of build scripts in
miXed won't make you happy in the long run.

Katja