Yeah I guess it makes sense to have a distinct extension. I haven't provided double precision externals yet because I think the binary should be easily available for those unaware of compiling magic first. And while we're at it, I guess it's time to provide them at miller's site and puredata.info
cheers Em ter., 29 de mar. de 2022 às 06:29, IOhannes m zmoelnig <[email protected]> escreveu: > > hi, > > TL;DR i'd like to suggest to use deken-specifiers as (optional) part of > external filenames, in order to allow co-installability of externals of > different OSs, architectures and floatsizes (and more to come). > > i would really love to push the double precision saga towards a (happy) > end. > we have been able to compile Pd for 64bit double precision numbers. > there's even a double-precision variant available in the Debian > "experimental" repositories (but who knows that?) > > *very* few people have started to provide externals (i counted: 4). > > afaict the biggest hurdle is that you can't really co-install single and > double variants of the same external. > since there are so few double-precision externals available, people who > rely on externals will be forced to use single-precision Pd for some time. > but since installing a double-precision external might overwrite an > existing single-precision external (required in your other project), i > understand why people are not exactly eager to do that.¹ > > > one solution to this problem is to use different installation paths > (e.g. ~/Documents/Pd/extra/ vs ~/Documents/Pd/extra64/). > this doesn't play well with how deken currently works (as it stores the > installation path globally (for all versions/variants of Pd). > > Lucas suggested to use different file extensions (a year ago...time > flies), by inserting `.float64` (and possibly `.float32`) right before > our known extension (so we get `foo.float64.m_amd64`) > I didn't especially like this back then, but in the meantime i've come > to the conclusion that it's probably the best way forward. > > however, i think that we might do better than just inserting a single > `.float64`, and just unify the entire naming scheme to hold all the > information we need. > > i'd therefore suggest to use the deken-specifier together with the > native extension (for dynamic-link libraries), as a new extension. > > the "native extension for dynamic-link libraries" is typically defined > on an OS level, and is something like ".dll" on Windows, ".dylib" on > macOS and ".so" in the un*x world. > > the "deken-specifier" is what we use in deken packages to know that they > contain binaries for your specific combination of CPU, OS and precision, > and looks like "<OS>-<CPU>-<precision>", e.g. "Darwin-arm64-32" (which > denotes a macOS binary ("Darwin") that runs on the M1 processor > ("arm64") and uses single-precision numbers ("32" bits). > > this would give us filenames like "zexy.windows-amd64-32.dll" > to keep things simple (and reduce the noise with -verbose), i would > suggest to only allow lower case specifiers, and no arch variants (e.g. > i386 for all x86_32 variants, and amd64 for all x86_64 variants) > > pros > > - using the system extension does not require us to invent our own > extension for each new platform > - system tools often use the file-extension to recognize the file type > - deken-specifiers fully cover what we need to know (the problem space > is the same for deken package files and externals: allow coexistence of > files with multiple OS/arch/precision specs) > - people can relate the files within a deken-package with the > deken-package-filename > - if we ever need to add a new parameter, the deken specifier and the > externals are likely to be affected in a similar way, so we need to > solve the problem only once. > - it gets rid of the super-cryptic .<first-letter-of-the-os>_<cpu-arch> > specifier (.o_ia64 anybody?) > > cons > > it shares the same (final) extensions as any support libraries. > eg. "zexy.linux-amd64-32.so" + "libzexy.linux-amd64-32.so" (or even > libzexy.linux-amd64-32.so.so, but I guess we don't want this) > > probably some more... > > > instead of using the system extension for dynamic libraries, we might > pick a general unified (final) extension, instead of the system ones, > e.g. .pdx (but that is already taken) or .pd_external. > but i think the less we invent ourselves, the better. > > > > Lucas had started a feature-request/discussion on this very topic a year > ago, but it was dormant until now. > > https://github.com/pure-data/pure-data/issues/902 > > i would like to hear your opinion on this (here or at the issue tracker; > or both), and eventually get this done. > > once this is solved, i will start to push Pd64 packages to the Debian > repositories, so people can start to use it (without having to compile > themselves). > > > gfmsdr > IOhannes > > > ¹ just for the record: the biggest hurdle is of course that there is no > double-precision download available right now... but that's a bit of an > egg-hen problem. > _______________________________________________ > Pd-dev mailing list > [email protected] > https://lists.puredata.info/listinfo/pd-dev >
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
