[PD] repackaging externals on Deken

[katja]

On Mon, Jan 23, 2017 at 1:04 PM, IOhannes m zmoelnig <zmoelnig at 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