I think it's better to use file extents than directory structure to disambiguate this, so that people can distribute "fat" externs within a single directory. If we want the suffix to combine both the architecture and the OS, maybe the best name scheme is
.lin_32 .lin_64 .lin_ppc .mac_ppc .mac_64 .msw_32 .msw_64
The original ".pd" business was to disambiguate between pd, jmax, "max 0.26" and Max/MSP, but now that that's down to only two offerings maybe that's not an issue right now.
cheers Miller
On Wed, Dec 21, 2005 at 11:06:36AM +0100, geiger wrote:
On Tue, 20 Dec 2005, Miller Puckette wrote:
OK, I'm liking "pd_win32" more and more. If Microsoft makes a new dll format that permits bundling, that would be a good moment to change the suffix again...
Which leads me to a question I always wanted to ask, but never dared to. What should be done on platforms that support more than one architecture, like linux or macosx ? Obvioulsy a xxx.pd_linux from a powerpc machine is not usable on a pentium, which makes bundling impossible. One would need a pd_linux_368, pd_linux_ppc, etc ...
G?nter
cheers Miller
On Tue, Dec 20, 2005 at 08:37:34PM +0000, c wrote:
"win32" would be nice to distinguish between that and "win64". However, if both 32-bit and 64-bit executables are likely to be packed into a same file, then ".pd_win32" as a suffix wouldn't make that much sense anymore.
it would make it much easier to figure out which files need to be deleted when upgrading to pd64, in 2038...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev