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