Lucas, I thought about your method, but it potentially involves several iterations and guesswork, and two machines.
I appreciate the help, but the method I want to pursue is the one I described.
I'll bet someone has already done this...
BH
On Mon, Jun 6, 2016 at 11:32 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Well, one simple trick is to have pd-vanilla installed on another machine (or a virtual machine). This will be the test environment, a neutral one with just pd-vanilla.
Prepare your folder with Main patch and abstractions.
Open it in the other/virtual machine.
You will get the console with a lot of messages alla “pink~ couldn't create”.
There you get the list of all things needed.
Then work out everything until there's no more “couldn't create ..”
You can collect all needed abstractions in a folder say “absz” an use [declare -path absz] and also collect all externals in “extz” and use [declare -path extz] or the same with lots of folders to include the licences i.e “extz/cyclone” (-path extz/cyclone) and the same for other externals which is more correct.
This also allows to include externals compiled for the 3 Os. Simply extract the 3 zips of “cyclone” and unify their content in one cyclone folder. (if you want you can exclude the binaries that you don`t need)
If more you need more in depth let me know.
Mensaje telepatico asistido por maquinas.
From: williamahuston@gmail.com Date: Mon, 6 Jun 2016 22:02:17 -0400 Subject: Re: [PD] Determine library dependency tree for a patch? To: lucarda27@hotmail.com CC: pd-list@lists.iem.at
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:
$ perl ShowPdDependencyTree.pl BillsPatch.pd
*BillsPatch.pd*
*|--------/home/bh/pd/abstractions/BillVerb~.pd*
*| ---------- /home/bh/pd/pd-0.43.4-extended/extra/freeverb.ld*
*|--------/home/bh/pd/abstractions/flanger~.pd| ---------------/home/bh/pd/abstractions/autophase12~.pd| ---------------/home/bh/pd/abstractions/autopan12~.pd| ---------- /home/bh/pd/pd-0.43.4-extended/extra/flatgui/knob.ld|--------/home/bh/pd/abstractions/MultiOsc~.pd*
*|*
*..... (etc.)......*
Make sense? I want this to be able to work anywhere why Pd works (OSX, Windows, Linux).
Thanks, BH
On Mon, Jun 6, 2016 at 9:30 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Hi William,
You can include all the externals that you need in your distribution.
You know that pd-vanilla will be there and you supply a folder (probably with sub-folders) with all externals (for all platforms if needed).
Then you simply use [declare]
That`s it.
You can download the zips of the externals with deken or from puredata.info.
Hope this helps, If you need more clarification on how to do this write back.
Or you are trying to do something that I don't understand.
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
From: williamahuston@gmail.com Date: Mon, 6 Jun 2016 16:52:32 -0400 To: pd-list@lists.iem.at Subject: [PD] Determine library dependency tree for a patch?
My idea is, I want to distribute a patch.
But I build my patches with layers of abstractions.
So I want to make a recursive map of the dependency tree, including any external libraries needed, so I can know what needs to be included when I distribute the patch.
Has anyone tried this?
I will probably do this with an external program, probably Perl (not within Pd).
First it seems I really need to understand how to Pd does conflict resolution in case of name clashes.
Next, it seems one must know the search path.
This is a bit easier on Linux systems b/c it just requires parsing a flat file.
On Windows it requires parsing the Registry (which I admit is still a big mystery for me).
On My machine, I am finding the search path here:
HKEY_USERS\S-1-5-21-1970324843-3388967453-2642309065-1000\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Pd\
npath=12 means 12 directories to search, each being path1=(path1) path2=(path2) ... path12=(path12)
I also find this repeated here:
HKEY_USERS\S-1-5-21-1970324843-3388967453-2642309065-1000_Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Pd
One question is, where does this strange string come from? Is this guaranteed to be the same on every Windows systems?
S-1-5-21-1970324843-3388967453-2642309065-1000 S-1-5-21-1970324843-3388967453-2642309065-1000_Classes
Ugh. Anyway, just looking for some general guidance here.
Thanks, BH
--
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
--
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)