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