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