On Mon, Jan 23, 2017 at 1:04 PM, IOhannes m zmoelnig <[email protected]> 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
