On 07/03/2016 03:06 PM, patrice colet wrote:
Le 03/07/2016 à 13:07, IOhannes m zmölnig a écrit :
#1 a deken package should be self-contained. if a given deken package lacks a library (e.g. libpthreadGCC3.dll) then it should provide that library itself. (alternatively, deken could be (theoretically; practically i see a number of hurdles) enhanced to explicitely state such dependencies (so installing "foo" would also install "pthreadGCC3")
#2 a deken package must be installable by deken. the requierement to "then put all the dlls into pd/bin" contradicts this. until deken can be told to install into pd/bin, i think that though shall not abuse the deken package system for such things.
Do you think it's possible for deken to:
1° add pd/bin to system's path, then pd pdsend and pdreceive will work with no pain in ms-dos console
this should be done by pd installer but for the moment I believe it doesn't,
since when are pdsend.exe and pdreceive.exe broken? if this is true, this is a rather severe bug in the w32 package of Pd.
so deken could at least resolve this.
hmm. whether it *could* is probably secondary. if deken could fix w32 security breaches, i would still be opposed to using it for these kind of things :-)
2° add dependencies to a place declared in system's path
admin rights would only be required when installing deken or last pd-vanilla
if by system path you mean something like "C:\Windows", then putting things there is asking for trouble, as this is likely to break unrelated software ("dependency hell").
apart from that: what deken currently does is to download zip-files and extract those zip-files somewhere in Pd's search path. this is a simple task, and deken was always meant to be simple. i don't see a way to keep that design and allow for things you ask (unzip doesn't allow such quirks)
so: i think the way to go is to create self-contained deken packages, that do not require anything outside their directory.
i'm under the vague impression that there *is* a way to have dll-dependencies live besides the dll (rather than the calling binary). though i also seem to remember that hans researched that and didn't come up with a proper solution (but then, Pd-extended could live without)
also, if it's absolutely impossible to have pthreadGCC2.dll live besides foo.dll (and have it instead live besides pd.exe), then i think the proper solution would be to re-compile foo, so it depends on the pthread-implementation that already comes with Pd.
gfmsrada IOhannes