<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1456343671203_6299">Just to add a bit on why build complexity is important:</div><div id="yui_3_16_0_1_1456343671203_6656" dir="ltr">I probably wasted 20% of my time building the GUI port on OSX due to the complexity of the flext build system. <br></div><div id="yui_3_16_0_1_1456343671203_6404" dir="ltr">And apparently I am not the only one who views it as voodoo, because the externals/Makefile calls <br></div><div id="yui_3_16_0_1_1456343671203_6453" dir="ltr">the flext "build.sh" one more time than the documentation says is necessary. (Which, btw, is officially a <br></div><div id="yui_3_16_0_1_1456343671203_6687" dir="ltr">total of 3 calls.)<br></div><div id="yui_3_16_0_1_1456343671203_6657" dir="ltr"><br></div><div id="yui_3_16_0_1_1456343671203_6659" dir="ltr">I say "waste" because I still don't have a working version of flext in the app bundle. Of course if I can <br></div><div id="yui_3_16_0_1_1456343671203_12923" dir="ltr">actually get it to work, I'll just leave it there and probably never touch it again like the rest of the Pd-extended <br></div><div id="yui_3_16_0_1_1456343671203_12922" dir="ltr">build monstrosity. :)<br></div><div id="yui_3_16_0_1_1456343671203_10793"><br></div><div id="yui_3_16_0_1_1456343671203_12667" dir="ltr">So a simple build process is worth its weight in gold. More than that, a non-standard build system is a good <br></div><div id="yui_3_16_0_1_1456343671203_12668" dir="ltr">filter for keeping new code out of the ecosystem-- both because it's too tedious to use, and too complex for the <br></div><div id="yui_3_16_0_1_1456343671203_12708" dir="ltr">community to maintain. (Where non-standard is anything other than autotools or make with the usual <br></div><div id="yui_3_16_0_1_1456343671203_12744" dir="ltr">targets.)<br></div><div id="yui_3_16_0_1_1456343671203_12848" dir="ltr"><br></div><div id="yui_3_16_0_1_1456343671203_6777" dir="ltr">-Jonathan</div><div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> On Wednesday, February 24, 2016 2:08 PM, katja <katjavetter@gmail.com> wrote:<br></font></div> <br><br> <div class="y_msg_container">On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres<br clear="none"><<a shape="rect" ymailto="mailto:porres@gmail.com" href="mailto:porres@gmail.com">porres@gmail.com</a>> wrote:<br clear="none">> 2016-02-24 14:17 GMT-03:00 katja <<a shape="rect" ymailto="mailto:katjavetter@gmail.com" href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>>:<br clear="none">>><br clear="none">>> the code was embedded in the programming structure of miXed, together with<br clear="none">>> other libraries and the shared framework (...) Since other libraries in<br clear="none">>> miXed were essentially unmaintained (...) I figured that cyclone's chances<br clear="none">>> for future maintenance would be best if it could be compiled with a build<br clear="none">>> system not relying on Pd-X or miXed as a set of libraries.<br clear="none">><br clear="none">><br clear="none">> Makes sense to me.<br clear="none">><br clear="none">> Well, first, thanks for all the detailed information on how cyclone grew<br clear="none">> into a giant kludge and current issues Katjia. So, It was brought to github<br clear="none">> conserving as many pieces of the original puzzle as possible. But well,<br clear="none">> yeah, seems like depending on old ways and days might be counterproductive<br clear="none">> on the long run as you mentioned. and it kinda relates to what Miller and<br clear="none">> others were telling about how cyclone should maybe be left alone as it was<br clear="none">> attached to "old ways of doing things", a new rebuild might be a good idea,<br clear="none">> though quite ambitious.<br clear="none"><br clear="none">Alexandre, your summary of my notes about cyclone's build systems (old<br clear="none">and new) make a totally different story than I was telling. Cyclone<br clear="none">didn't grow into a kludge, only the build system did. That is now<br clear="none">solved as far as I am concerned.<br clear="none"><br clear="none">For the rest: cyclone and it's underlying framework form a<br clear="none">well-structured but never completed body of code. I don't think anyone<br clear="none">suggested to rewrite it, if that is what you mean with 'rebuild'.<br clear="none">Rewriting is ambitious indeed, possibly beyond your imagination. And a<br clear="none">waste of time. Better focus on new functionality, and leave or<br clear="none">delegate maintenance of the existing code base to people who are able<br clear="none">and willing to understand it's structure.<br clear="none"><br clear="none">Katja<div class="yqt7471987705" id="yqtfd46703"><br clear="none"><br clear="none">><br clear="none">>><br clear="none">>> Of course it is technically possible to add new classes which don't<br clear="none">>> use the framework functions (...) You can have independent repositories,<br clear="none">>> test / release cycles, and support (...) if the outcome of the discussion is<br clear="none">>> that all must go in one cyclone lib, you could at least organize source tree<br clear="none">>> and build system in such a way that dependencies between categories of<br clear="none">>> classes and underlying framework remain transparent. The build system could<br clear="none">>> be split according to categories of classes so devs can work in relative<br clear="none">>> isolation in between releases.<br clear="none">><br clear="none">><br clear="none">> For now, I'm revising all the documentation and painstakingly correcting it<br clear="none">> and testing objects looking for current issues. I've covered one third of<br clear="none">> the audio objects to this moment (26), only 8 have no remarks. This is a<br clear="none">> very time consuming task. I might take a month to recheck all current state<br clear="none">> of objects.<br clear="none">><br clear="none">> I can propose a new beta release with minor bug fixes right away just for a<br clear="none">> test, keeping things basically the way they already were. There's time to<br clear="none">> think about everything else when this new report of the current state is<br clear="none">> complete.<br clear="none">><br clear="none">>> here's my recommendation: make use of the new build<br clear="none">>> approach, because dealing with the old kludge of build scripts in<br clear="none">>> miXed won't make you happy in the long run.<br clear="none">><br clear="none">><br clear="none">> Agreed, thanks for the notes again.<br clear="none">><br clear="none">> Cheers<br clear="none"><br clear="none">_______________________________________________<br clear="none"><a shape="rect" ymailto="mailto:Pd-list@lists.iem.at" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>