On Mon, Jan 23, 2017 at 1:04 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-01-21 11:50, katja wrote:
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).
Ah cool. So you make the path unambiguous by using the leading slash (i.e. "./<object>" for an object that sits next to the patch, etcetera).
Happy! This method is great for test patches (unit tests, regression tests) where you want to be sure to test the intended build. The overwriting behavior isn't so elegant in some other cases though.
i haven't tested how (and if) this works with [declare].
As far as I could check, [declare] does not have the effect of overwriting a class.
fgamsdr IOhannes
Katja