On Sep 21, 2010, at 2:19 PM, Hans-Christoph Steiner wrote: > From what I rememeber, it was excluded because it was non-functional the way > it was included. There is a bug that prevents the libdir packaging working > when the folder has the same name as the abstraction in it, i.e. > sssad/sssad.pd. T > This works with binary externals. > > As for alternate ways of including things besides libdirs, there are lots of > kludges currently in Pd-extended. I've been spending a lot of my time > maintaining them. I'm working on reducing maintenance time so I can actually > spend time coding new things. So far, only a couple people have a track > record of actually maintaining code in Pd-extended without me needing to get > involved (Martin Peach, Matju, Roman, IOhannes, I'm probably missing someone). > > So I think the way forward is to make it easy for people to distribute their > own libraries on their own, and make them really easy to install and use. > Pd-extended 0.42.5 and Pd-vanilla 0.43 have big improvements in that regard, > so people should try that path first (i.e. package as libdir, make the libdir > usable when dropped into the standard user install paths in the FAQ, etc.)
Ok, so the emphasis will be on less included libs within pd-ext in the future and more on the lib framework making externals easy to install? I think we mainly need a sort of "externals" portal on the website where everyone registers libs so its a one-stop shop for picking your object poison. This makes more sense then an every growing blob within pd-extended. -------- Dan Wilcox danomatika.com robotcowboy.com
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
