One "con" I can imagine is that there are "cleaner" alternatives than name mangling.
For example, VST3 plugins use a bundle structure which also allows for "merged bundles": https://developer.steinberg.help/display/VST/Plug-in+Format+Structure.
Something similar *could* work for Pd externals:
foo-lib/
-- bar.pd/
---- windows-amd64-64/bar.dll
---- windows-amd64-32/bar.dll
---- linux-amd64-64/bar.dll
---- linux-amd64-32/bar.dll
etc.
In this case, the .pd extension would be used both for Pd abstractions and external binary bundles.
But it might be overkill...
Christof
On 29.03.2022 17:49, Roman Haefeli wrote:
On Tue, 2022-03-29 at 17:29 +0200, Christof Ressi wrote:
+1
+1
I think it's nicer to use a common extension and have the platform/arch/floatsize specifier as a seperate component.
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.
Why? I think it is much friendlier for the user to see in the filename what is in it. If binaries are distinguished by installing them to separated folders (but still share filename), people will try to move files around to make things work and thus getting into a mess really quickly. One shouldn't have to use 'file pdexternal.ext' to know what actually is in it.
Having said that, I'm still curious to know what you thought are the cons back then. Roman
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev