[PD-dev] help me with my DLL snafu

Hans-Christoph Steiner hans at eds.org
Fri Dec 23 09:04:38 CET 2005


After going thru all of the disparate proposals, I think that the  
simplest is best:  why not just one extension for all platforms?  This  
is how programs like Photoshop do it, for example.  As for the fat  
library, that is an interesting idea, but that could be done with named  
directories as well.  And since this would be a rare case, it seems  
that making the common cases simpler would be preferred.

Almost all packages which are compiled for distribution are done on on  
the processor/platform that they are targeted for.  So its relatively  
straightforward to package the compiled files separately for each  
platform.  This is how its currently done with Pd and Pd-extended, for  
example

.hc

On Dec 22, 2005, at 1:09 PM, c wrote:

>> Both Perl and Ruby use directories labeled like i386-linux and
>
> what exactly is the purpose of this? maybe some crazy netboot AFS
> setup for an entire university that had a sitewide ruby or perl
> install but everyone had arch specific interpreter binaries in their
> $HOME/bin? i just don't see it...even on a multilib system, its not
> like theres a /usr/lib/ruby/i8086-hurd/bin/ruby, yet for the
> extensions theres /usr/lib64/ruby/1.8/x86_64-linux and
> /usr/lib32/ruby/1.8/i686-linux -> the second platform specification is
> redundant and could easily be replaced by 'lib' or 'extra' or such...
>
> the most fitting thing for pd would probably be branch-specific dirs,
> for example itd be great when running canonical it didnt bomb out
> loading externals that reference a fftw symbol or use idle callbacks,
> and likewise id rather not have stock devel try to load GUI externals
> compiled for desire_devel...etc. it got to the point i had to
> recompile externals every time i was switching pd versions (maybe
> version-specific .pdrc sections would work too...)
>
> not that anyone would want to externalize these differences onto the
> filesystem, but they exist anyway, and the user is far more likely to
> run into them then accidentally ending up with a darwin external on
> their windows install??
>
> c
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>

________________________________________________________________________ 
____

If you are not part of the solution, you are part of the problem.
                                                                          
                            - Eldridge Cleaver





More information about the Pd-dev mailing list