[PD] libdirs and search-plugin

[Hans-Christoph Steiner]

On Mar 20, 2012, at 3:41 AM, IOhannes m zmoelnig wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2012-03-19 21:03, Hans-Christoph Steiner wrote:
>> 
>> Yes, in scripts/ in pure-data SVN.  You're best bet for getting Gem to accept the meta files is to submit them to the pd-gem tracker.  For this release of Pd-extended 0.43, Gem is already imported into the pd-extended/0.43 branch in SVN, so you can commit directly there.
>> 
> 
> while of course i have no problem with including a Gem-meta.pd, i think
> i remember that there where problems related to that simplistic approach.
> 
> Gem (as is and will stay for the foreseeable future), is a
> single-binary-multiple-object library.
> adding a "Gem-meta.pd" will make [import Gem] search for and find
> "Gem/Gem-meta.pd" and happily report the Gem libdir(!) to be loaded
> while this is really not enough to make Gem do anything at all.
> I assume that people will then complain that Gem is "broken" because it
> doesn't work even though [import] reports it should, while really only
> the import mechanism cannot deal with Gem's reality.
> 
> my suggestion to make the -meta.pd patches something like proper
> "__init__" thingies, allowing a library to bootstrap itself where
> unfortunately turned down (i'm sure for good reasons).
> 
> so this is the reason why there is no Gem-meta.pd (yet).
> if my assumptions above are not true or don't matter, i guess there is
> no reason to not add it.


I did a quick test, I just added a blank Gem-meta.pd file to Gem in Pd-extended.  It did not seem to prevent Gem from loading, either using [import Gem] and "pd -noprefs" or just the default loading of Gem via the prefs.

I think that Gem/Gem.pd_linux comes before Gem/Gem-meta.pd in the list of priorties.

.hc

----------------------------------------------------------------------------

Access to computers should be unlimited and total.  - the hacker ethic