[PD] [PD-announce] Deken package with missing dlls for old-extended externals (w32).

[IOhannes m zmölnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160703/3a10c9ec/attachment.sig>