[PD] w32 Deken package issues.

Lucas Cordiviola lucarda27 at hotmail.com
Mon Jul 11 16:26:14 CEST 2016


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 at hotmail.com; pd-list at lists.iem.at
From: colet.patrice at 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.

        

        

        
      
    
    
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160711/6b467a24/attachment-0001.html>


More information about the Pd-list mailing list