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@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