Add binary definitions for others systems than linux, macos and win

[falkTX]

Hi there. I am starting to make VST3 compatible versions of my plugins. One issue that I found that needs to be resolved on the specification side is what to use for the filename for systems outside of linux, macos and windows. BSD is one of such systems, so it seems like using "bsd" as a filename string would be the way to go, but there are more.. (my plugins work on pretty much anything that is posix-compatible, so macos, linux, bsd, be/haikuos, fuchsia, hurd and whatever else exists out there)

So currently it is not possible to ship a BSD-compatible VST3 binary.

Please add/mention something in the spec in regards to this situation, or at least link to an existing naming scheme we can use. Thanks.

[falkTX]

Any ideas on this? Cardinal has been released for FreeBSD, but the build is broken because we don't have a proper definition. https://github.com/DISTRHO/Cardinal/issues/148

@yurivict maybe just assume "bsd" as string to use on FreeBSD stuff? "linux" and "win" are in use, IMO "bsd" makes the most sense, even without official acknowledgement. We might be here waiting forever otherwise...

[yurivict]

"bsd" sounds like a good choice.

[ygrabit]

@falkTX @yurivict We have no experience in the BSD world, but before having any decision we need to be sure that it fulfils some requirements. Are built library binaries compatible between all BSD OS variants?

[yurivict]

Are built library binaries compatible between all BSD OS variants?

No.

Then I suggest the name should be "freebsd".

[ygrabit]

You can use then "freebsd" as basename, we will add it later in our documentation (in 1 year) if there is no objection or technical issue..

[falkTX]

While appreciated, that only covers the case of freebsd.

I already have working vst3 plugins on haikuos and gnu hurd. Likely they will just work on any posix-compatible system. If you take a look at this wikipedia page you will see it is quite of lot of systems. But I cannot enable vst3 support for them, simply because the spec is incomplete.

Why not just go with some name convention, instead of trying to define it for every single system available? For file paths, should be quite easy to define them for the OSes that are esoteric in nature (BeOS, macOS and Windows) and leave the Linux/BSD/POSIX-etc crowd as fallback with the generic /usr/lib/vst3 like stuff.

[yurivict]

@falkTX Maybe a good strategy is to just introduce some reasonable convention and let all dependent projects to proceed. And if later the spec would be different - update the code then.

[falkTX]

do you know of a good convention we can use?

in my opinion this separation of binaries per build type goes against the typical packaging where the distribution repository provides native binaries directly. I mean, someone in freebsd installing a plugin will get the freebsd version matching its running system. if we install it in debian, we get a debian build, etc etc. so this whole multiple different pathnames doesnt make a whole lot of sense here, just adds confusion.

for a plugin host running on linux ARM, this is a whole mess with needing to load the matching arch file (e.g. linux-armv8) but that might be missing and instead plugin ships a linux-armv7 version instead. hosts need to search for the best match, which is seriously annoying.

anyhow, if we fail to find a good set of rules to follow, we can just let each distribution state how they prefer to handle VST3 paths.