[PD] >, <, &&, || etc
IOhannes m zmoelnig
zmoelnig at iem.at
Mon Apr 6 11:26:06 CEST 2009
Hans-Christoph Steiner wrote:
>
> So a library like 'audiomath' would then have
> audiomath/libaudiomath.pd_linux. Normally,
> audiomath/libaudiomath.pd_linux would only include shared code, but for
> this case, it would also include the >~ class, etc.
i guess you meant to name it either "audiomath/libaudiomath.so" (or .dll
or .dylib) or "audiomath/audiomath.pd_linux".
the latter is btw, similar to what zexy and/or Gem suggest "upstream"
(that is: from my side; not to be confused with any packagers'
versions):: zexy/zexy.pd_linux holds shared code (e.g. [>~]) and
signle-file-object live side-by-side to it, e.g. rad2deg.pd;
i admit that currently all C-code is considered "shared" (that is: there
is no "list2symbol.pd_linux"), but once you start blurring the two
worlds it get's blurry anyhow (and "l2s" and "list2symbol" share about
100% of their code anyhow)
having said all that, i think it is a good idea: i would like to be able
(e.g. in Pd-extended) to "load" Gem (without modifying the path!) and it
should find Gem/Gem.pd_linux and add Gem/ to it's search paths (for
abstractions and single-file externals)
i would also like to have Pd's loading mechanism modified so that it
_temporarily_ adds Gem/ to the dylib-searchpath, so one could ship a
library with external dependencies (without having to link them statically)
fmgadsr
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090406/ce4b8223/attachment.bin>
More information about the Pd-list
mailing list