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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
