On 2017-01-21 11:50, katja wrote: > Choosing a unique name for an external is indeed the best warranty to avoid > conflicts.
the problem is of course to create those "unique" names.
"context_initbang" could easily nameclash.
UUID could be used, but has other drawbacks
("091f5a12-43e0-482b-8be1-6e1ee3757cdc" anybody?)
> Not only a future release of a dependency has the potential to
> break your patch. An old release with a bug or missing feature can do that
> too! It seems there's no way to force Pd loading the executable that sits
> in your project tree (I would be very happy if someone can prove me wrong).
well iirc, you should be able to force-load a library by using it's
"fully" qualified filename.
that is, if you have an object [../context/iemguts/initbang], Pd
wouldn't know how to create that, and start its library loading
mechanism, eventually finding the ../context/iemguts/initbang.pd_linux
file and loading it. doing so will - as a side effect - overwrite the
constructor of "initbang", so any [initbang] instantiated therafter will
be *this* version.
(until Pd encounters an object [../cuntaxt/initbang] overwrite the
constructor for "initbang" again).
i haven't tested how (and if) this works with [declare].
fgamsdr
IOhannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
