On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres <por...@gmail.com> wrote: > 2016-02-24 14:17 GMT-03:00 katja <katjavet...@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