yep, when you need to compile some stuff, pd-extended is not really made for you. since i quite often have to use a very recent Gem version for my project, (specially when i correct some Gem bugs when working on this project), i must recompile Gem on the target machine, so using extended is not really easy. using extended is ok when installing a project i made about 1 year ago...
Cyrille IOhannes m zmoelnig a écrit : > Frank Barknecht wrote: >> Hallo, >> cyrille henry hat gesagt: // cyrille henry wrote: >> >>> this is what i was thinking for the last 5 year. i don't say that this >>> will never change. anyway, i really appreciate the work made on >>> pd-extended, but it is not ready for me yet. i know that my position >>> is a bit extreme, but i don't really have problem with it. >> >> I have a similar position. :) >> >> To me the problem of Pd-extended or the reason why I don't use it is >> because it is not only a collection of externals and abstractions, but >> it also bundles it with a modified, often out-of-date version of Pd >> into a big monolithic package. >> > > > i guess one of the main reasons for us (the iem) to not use pd-extended > is, that it is targeted at people without compilers, whereas we often > develop libraries for our projects. > (Pd-extended is severely limited in this respect, e.g. the 103MB disk > image on OSX comes without g_canvas.h) > > > fmasd.r > IOhannes > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
