On Thu, 2012-04-12 at 16:00 -0700, Jonathan Wilkes wrote:
From: José Rafael Subía Valdez jsubiavaldez@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: pd-list pd-list@iem.at Sent: Thursday, April 12, 2012 6:40 PM Subject: Re: [PD] libdir question (was: Re: pduino patches on pdx)
Its adressed to hans.. but maybe.. just maybe
[declare -path name]
this should work
It works if I then use [bar], but if I use [abs2/bar], it fails.
Let me see if I can clarify the question:
How do I design a library "foo" (of abstractions) so that it can use abstractions
from library "bar" if "bar" is installed to the system libdir location, but also so that it can use abstractions from "bar" when both "foo" and "bar" are shipped with the patch in its
directory?
For example, let's say my "foo" library uses some abstractions from list-abs. I'd like to
design it so that I can ship my patch with "foo" and "list-abs" included with it, but also so
that "foo" can be used by anyone who downloads it and already has list-abs installed. I
can't think of a way to do that, other than making "list-abs" a subdirectory of "foo", which is
ugly.
It works, if you put [declare -path .] into those abstraction of your foo library, that require the list-abs library.
Mind the the dot, it's not '..', as someone would probably consider more intuitive. This is because [declare] inside abstractions expands the path relative to the topmost parent patch's location, not relative to the abstractions own location.
This example really works only when the main patch is in the same folder as your optionally shipped list-abs library.
Even if this solves your initial problem, I wouldn't use this solution, because in order for it to work correctly, your abstractions from foo need to make an assumption about the relative path between the topmost parent patch and the list-abs directory.
Roman