[PD-dev] packaging loaders for Debian
IOhannes m zmoelnig
zmoelnig at iem.at
Wed Sep 8 09:32:05 CEST 2010
On 2010-09-06 17:41, Hans-Christoph Steiner wrote:
>
>
> Why do you think having the ability to autoload loaders is a bad idea?
> I can't see a disadvantage, but I am not saying there couldn't be one.
> I would like to see it be possible to write Pd objects in a bunch of
> different langauges, then transparently use them as if they were any Pd
> object. Here's how I see it:
>
> - there is a library of nice GUI objects using tclpd
> - that gets packaged up Pd-extended, Debian, pure:dyne, etc.
> - someone else goes looking for GUI objects and finds the niceGUIobjects
> lib
> - they [import niceGUIobjects] and try making objects
> - they get lots of errors in the Pd window and no GUI objects
>
> Seems to me that for users, tclpd should already be loaded.
>
actually i think that it is [import]'s job to make sure that all the
dependencies are fullfilled in order to actually use that library.
so i believe that niceGUIobjects-meta.pd should have a "require tclpd"
equivalent (which of course has the scope of the patch containing the
[import] object)
having inter library dependencies, is not only a problem with loaders
(though loaders illustrate it nicely).
e.g. if i do [import GridFlow] without having Gem loaded, this will
eventually fail, because GF uses Gem's symbols but the dlinker has no
way of finding out that it is Gem.pd_linux that provides these symbols.
fmgasdr
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20100908/8c9b19a6/attachment.bin>
More information about the Pd-dev
mailing list