Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
falkTX opened this issue Sep 29, 2021 · 8 comments
Open

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

falkTX opened this issue Sep 29, 2021 · 8 comments

Comments

@falkTX
Copy link

falkTX commented Sep 29, 2021

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
Copy link
Author

falkTX commented Feb 15, 2022

Any ideas on this?
Cardinal has been released for FreeBSD, but the build is broken because we don't have a proper definition.
DISTRHO/Cardinal#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
Copy link

"bsd" sounds like a good choice.

@ygrabit
Copy link
Contributor

ygrabit commented Feb 17, 2022

@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
Copy link

Are built library binaries compatible between all BSD OS variants?

No.

Then I suggest the name should be "freebsd".

@ygrabit
Copy link
Contributor

ygrabit commented Mar 17, 2022

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
Copy link
Author

falkTX commented Mar 17, 2022

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
Copy link

yurivict commented Dec 31, 2022

@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
Copy link
Author

falkTX commented Dec 31, 2022

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.

@falkTX falkTX changed the title Add binary definitions for others systems other linux, macos and win Add binary definitions for others systems than linux, macos and win Aug 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants