Seems to me like you'd want some kind of script to parse your Pd patch, iteratively look through all the objects declared and look for them in pre-defined search paths.

I'm not 100% on what the hierarchy is in Pd, but probably start with paths added by [declare -path], relative sub directories, global user defined paths in Pd, and the normal Pd extern folder?

You'll probably want to compile a list of internal objects to check against as well.

On 7 June 2016 at 10:43, Frank Barknecht <fbar@footils.org> wrote:

On Mon, Jun 06, 2016 at 10:02:17PM -0400, William Huston wrote:
> Yes, my plan is to include whatever abstractions in my own libraries.
> But I do not know what those dependencies are!!
> That is the problem.
>
> My goal is to have a script or program which can
> a) examine an arbitrary patch, (example: "BillsPatch.pd") and
> b) examine my Pd runtime environment
>
> ... and build a dependency tree. Something like this:

Maybe for starters you can start with Pd itself in a shell-like script and examine its output?
With "-verbose" you get explicit error lines for every object missed and
found like this:

$ pd -stderr -noprefs -verbose somepatch.pd
[...]
tried /tmp/somepatch.pd and succeeded
tried /tmp/a/in-b.l_ia64 and failed
tried /tmp/b/in-b.l_ia64 and failed
tried /tmp/in-b.l_ia64 and failed
tried /home/fbar/pd-externals/in-b.l_ia64 and failed
tried /usr/local/lib/pd-externals/in-b.l_ia64 and failed
tried /usr/lib/puredata/extra/in-b.l_ia64 and failed
tried /usr/lib/pd/extra/in-b.l_ia64 and failed
[...]
tried /usr/lib/pd/extra/in-b/in-b.pd_linux and failed
tried /tmp/a/in-b.pd and failed
tried /tmp/b/in-b.pd and succeeded

Look for all "tried ... and succeeded" lines and extract the path or file.

When testing if you have everything copyied, use "-noprefs" as well to
ignore your own preferences.

Ciao
--
Frank Barknecht _ ______footils.org__

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list