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
2016-02-24 14:17 GMT-03:00 katja katjavetter@gmail.com:
the code was embedded in the programming structure of miXed, together with other libraries and the shared framework (...) Since other libraries in miXed were essentially unmaintained (...) 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.
Makes sense to me.
Well, first, thanks for all the detailed information on how cyclone grew into a giant kludge and current issues Katjia. So, It was brought to github conserving as many pieces of the original puzzle as possible. But well, yeah, seems like depending on old ways and days might be counterproductive on the long run as you mentioned. and it kinda relates to what Miller and others were telling about how cyclone should maybe be left alone as it was attached to "old ways of doing things", a new rebuild might be a good idea, though quite ambitious.
Of course it is technically possible to add new classes which don't use the framework functions (...) You can have independent repositories, test / release cycles, and support (...) 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 in between releases.
For now, I'm revising all the documentation and painstakingly correcting it and testing objects looking for current issues. I've covered one third of the audio objects to this moment (26), only 8 have no remarks. This is a very time consuming task. I might take a month to recheck all current state of objects.
I can propose a new beta release with minor bug fixes right away just for a test, keeping things basically the way they already were. There's time to think about everything else when this new report of the current state is complete.
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.
Agreed, thanks for the notes again.
Cheers
On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres porres@gmail.com wrote:
2016-02-24 14:17 GMT-03:00 katja katjavetter@gmail.com:
the code was embedded in the programming structure of miXed, together with other libraries and the shared framework (...) Since other libraries in miXed were essentially unmaintained (...) 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.
Makes sense to me.
Well, first, thanks for all the detailed information on how cyclone grew into a giant kludge and current issues Katjia. So, It was brought to github conserving as many pieces of the original puzzle as possible. But well, yeah, seems like depending on old ways and days might be counterproductive on the long run as you mentioned. and it kinda relates to what Miller and others were telling about how cyclone should maybe be left alone as it was attached to "old ways of doing things", a new rebuild might be a good idea, though quite ambitious.
Alexandre, your summary of my notes about cyclone's build systems (old and new) make a totally different story than I was telling. Cyclone didn't grow into a kludge, only the build system did. That is now solved as far as I am concerned.
For the rest: cyclone and it's underlying framework form a well-structured but never completed body of code. I don't think anyone suggested to rewrite it, if that is what you mean with 'rebuild'. Rewriting is ambitious indeed, possibly beyond your imagination. And a waste of time. Better focus on new functionality, and leave or delegate maintenance of the existing code base to people who are able and willing to understand it's structure.
Katja
Of course it is technically possible to add new classes which don't use the framework functions (...) You can have independent repositories, test / release cycles, and support (...) 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 in between releases.
For now, I'm revising all the documentation and painstakingly correcting it and testing objects looking for current issues. I've covered one third of the audio objects to this moment (26), only 8 have no remarks. This is a very time consuming task. I might take a month to recheck all current state of objects.
I can propose a new beta release with minor bug fixes right away just for a test, keeping things basically the way they already were. There's time to think about everything else when this new report of the current state is complete.
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.
Agreed, thanks for the notes again.
Cheers
Just to add a bit on why build complexity is important:I probably wasted 20% of my time building the GUI port on OSX due to the complexity of the flext build system. And apparently I am not the only one who views it as voodoo, because the externals/Makefile calls the flext "build.sh" one more time than the documentation says is necessary. (Which, btw, is officially a total of 3 calls.)
I say "waste" because I still don't have a working version of flext in the app bundle. Of course if I can actually get it to work, I'll just leave it there and probably never touch it again like the rest of the Pd-extended build monstrosity. :)
So a simple build process is worth its weight in gold. More than that, a non-standard build system is a good filter for keeping new code out of the ecosystem-- both because it's too tedious to use, and too complex for the community to maintain. (Where non-standard is anything other than autotools or make with the usual targets.)
-Jonathan
On Wednesday, February 24, 2016 2:08 PM, katja <katjavetter@gmail.com> wrote:
On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres porres@gmail.com wrote:
2016-02-24 14:17 GMT-03:00 katja katjavetter@gmail.com:
the code was embedded in the programming structure of miXed, together with other libraries and the shared framework (...) Since other libraries in miXed were essentially unmaintained (...) 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.
Makes sense to me.
Well, first, thanks for all the detailed information on how cyclone grew into a giant kludge and current issues Katjia. So, It was brought to github conserving as many pieces of the original puzzle as possible. But well, yeah, seems like depending on old ways and days might be counterproductive on the long run as you mentioned. and it kinda relates to what Miller and others were telling about how cyclone should maybe be left alone as it was attached to "old ways of doing things", a new rebuild might be a good idea, though quite ambitious.
Alexandre, your summary of my notes about cyclone's build systems (old and new) make a totally different story than I was telling. Cyclone didn't grow into a kludge, only the build system did. That is now solved as far as I am concerned.
For the rest: cyclone and it's underlying framework form a well-structured but never completed body of code. I don't think anyone suggested to rewrite it, if that is what you mean with 'rebuild'. Rewriting is ambitious indeed, possibly beyond your imagination. And a waste of time. Better focus on new functionality, and leave or delegate maintenance of the existing code base to people who are able and willing to understand it's structure.
Katja
Of course it is technically possible to add new classes which don't use the framework functions (...) You can have independent repositories, test / release cycles, and support (...) 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 in between releases.
For now, I'm revising all the documentation and painstakingly correcting it and testing objects looking for current issues. I've covered one third of the audio objects to this moment (26), only 8 have no remarks. This is a very time consuming task. I might take a month to recheck all current state of objects.
I can propose a new beta release with minor bug fixes right away just for a test, keeping things basically the way they already were. There's time to think about everything else when this new report of the current state is complete.
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.
Agreed, thanks for the notes again.
Cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'm certainly not able to grasp the whole deal, maybe just get the gist of it and certainly willing to. But I'm partnered with a colleague that I believe is technically capable besides only willing. We'd need a lot of "filling us in" though.
cheers
2016-02-24 16:05 GMT-03:00 katja katjavetter@gmail.com:
On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres porres@gmail.com wrote:
2016-02-24 14:17 GMT-03:00 katja katjavetter@gmail.com:
the code was embedded in the programming structure of miXed, together
with
other libraries and the shared framework (...) Since other libraries in miXed were essentially unmaintained (...) 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.
Makes sense to me.
Well, first, thanks for all the detailed information on how cyclone grew into a giant kludge and current issues Katjia. So, It was brought to
github
conserving as many pieces of the original puzzle as possible. But well, yeah, seems like depending on old ways and days might be
counterproductive
on the long run as you mentioned. and it kinda relates to what Miller
and
others were telling about how cyclone should maybe be left alone as it
was
attached to "old ways of doing things", a new rebuild might be a good
idea,
though quite ambitious.
Alexandre, your summary of my notes about cyclone's build systems (old and new) make a totally different story than I was telling. Cyclone didn't grow into a kludge, only the build system did. That is now solved as far as I am concerned.
For the rest: cyclone and it's underlying framework form a well-structured but never completed body of code. I don't think anyone suggested to rewrite it, if that is what you mean with 'rebuild'. Rewriting is ambitious indeed, possibly beyond your imagination. And a waste of time. Better focus on new functionality, and leave or delegate maintenance of the existing code base to people who are able and willing to understand it's structure.
Katja
Of course it is technically possible to add new classes which don't use the framework functions (...) You can have independent repositories, test / release cycles, and support (...) 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 in between releases.
For now, I'm revising all the documentation and painstakingly correcting
it
and testing objects looking for current issues. I've covered one third of the audio objects to this moment (26), only 8 have no remarks. This is a very time consuming task. I might take a month to recheck all current
state
of objects.
I can propose a new beta release with minor bug fixes right away just
for a
test, keeping things basically the way they already were. There's time to think about everything else when this new report of the current state is complete.
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.
Agreed, thanks for the notes again.
Cheers
-
Alexandre Torres Porres -
Jonathan Wilkes -
katja