Re: [PD] w32 Deken package issues.

Yes I forgot to mention the path where resides pd binary, but I did in the first mails of this thread... But this is same problem, there is no method in deken to put those dll in pd/bin dir, users have to do this manually.

Perhaps I wasn`t clear, pthreadGC2.dll inside mrpeach folder renders OPERATIONAL [tcpclient] and other objects. This conform IOhannes intention that deken pkgs should be self operational, I.e no need to place anything outside the external folder.

Mensaje telepatico asistido por maquinas.

Subject: Re: [PD] w32 Deken package issues. To: lucarda27@hotmail.com; pd-list@lists.iem.at From: colet.patrice@free.fr Date: Mon, 11 Jul 2016 16:11:26 +0200

Le 11/07/2016 16:04, Lucas Cordiviola a
  écrit :






      oupse, I didn't see it hidden in wow64 folder, the
          good new is that only 
      externals/Makefile have to be tweaked for using
          pthreadVC.lib in pd/bin




    Are you sure pthreadVC.lib is going to have longevity?
    What if Miller change this?







It's up to Miller, then we tweak Makefile again...






      I think it's fixed now, so I make an archive with all
          mrpeach objects I 
      could compile, and send it in a personal mail
          attachement for testing in 
      windows10.




    No problem, I`ve set a win10 virtual machine.




      The bad new is that my windows machine is dying but
          might build a few 
      packages and a externals/Makefile patch before
          leaving,
      could you test this package? If I do other packages
          would you mind 
      trying them before I publish?




    No problem, as fast as I can.




      It's not as simple as that because pd uses to look for
          external's third 
      party DLL into system path, not pd path, maybe it's
          different now?




    I think you`r wrong here, on my tests third party Dlls in
      the same dir as the external worked fine(two tests) and Zip
      versions of pd-extended (no need to install, unzip and run)
      method was putting them in pd/bin
    This is why I think is best to include the third party Dll
      in the deken package, along with the objects Dlls










Yes I forgot to mention the path where resides pd binary, but I did
in the first mails of this thread... But this is same problem, there
is no method in deken to put those dll in pd/bin dir, users have to
do this manually.










    Mensaje
      telepatico asistido por maquinas.