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
[email protected]
https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev
