OSX and/or Linux support?

[myrsloik]

OSX is probably more interesting since it's easier to distribute binaries. Opinions and the will to support things welcome.

[mia-0]

Linux support is made difficult by the fact that each plugin uses a different build system and may have dependencies on third-party libraries and other plugins at runtime, which makes automatic packaging next to impossible. I don’t think we can avoid extra maintenance overhead unless we come up with vapoursynth-specific metadata and/or tooling which needs to be adopted by all plugins (perhaps that would be a good idea in general). I would vote for just using Meson plus a little metadata to make packaging easier.

On the other hand, all it takes to support the most common binary distros right now is somebody watching the commit feed and manually pushing packages to OBS. I volunteer.

With the aforementioned changes, though, it wouldn’t be hard for me to automate package builds for at least RPM-based distros (since those have sane tooling and packaging practices, contrary to literally all other distros), as well as Windows builds (plus whatever repo metadata you want) using my own OBS instance.

[theChaosCoder]

Could snap/flatpak/AppImage be used to create distro independent libs/packages?

[myrsloik]

Another option would be to simply enable the script fetching part since it's portable. No idea if that's enough to be considered useful.

[mia-0]

Re Snap/Flatpak/AppImage: These don’t solve any problems in practice. Cross-distro packaging itself is not an issue if you just know what you’re doing, especially not for FOSS projects which can be freely distributed. What is an issue is the way 3rd party plugins and scripts are organized right now. Some other projects use streamlined build systems for plugins, which makes implementing and maintaining a plugin registry much easier.

Also, getting those app bundles to work can be much more difficult than just packaging for a dozen distros, depending on the requirements (like loading 3rd party plugins), and they don’t even apply to libraries. And they’re very bad at handling updates.

[Bl4Cc4t]

You could use Homebrew for osx. I already created a tap for many plugins: homebrew-vsplugins.
Maybe it’s possible to implement a call()? :)

[myrsloik]

Why didn't you tell me about this sooner? Will add it to the documentation. Did you ever consider adding the 10 most popular scripts as well?

[Bl4Cc4t]

I’m not sure on how to install single script files via Homebrew.
They’ll have to be put in different directories for each individual :V
e.g. my path is ~/.pyenv/versions/3.6.4/envs/jupyter3/lib/python3.6/site-packages

[darealshinji]

Why not write a build system for Linux similar to homebrew, pkgsrc or mxe

[myrsloik]

Why not write a build system for Linux similar to homebrew, pkgsrc or mxe

Nononononono! The answer is never to make your own build system.

[darealshinji]

Can you let vsrepo download the sources of the plugins? That alone would be very convenient on non-Windows systems. Y'know, kinda like running apt source PKGNAME.

By the way, many of the plugins are not linked against any third-party libraries (only stdc++, libgcc and glic on Linux), so adding macOS and x86-64 Linux builds for at least those plugins to the release section shouldn't be much of a problem I think.

[theChaosCoder]

Since there are now 100 ported/compiled plugins for macOS (https://forum.doom9.org/showthread.php?t=175522) it deserves some vsrepo love too.

I think vsrepo portable mode should already be 99% compatible with macos since all it does is downloading and extracting files. Idk if vapoursynth plugins are always installed in the same place on mac "/usr/local/lib/vapoursynth"

The package definition could be extended like this:

"mac64": {
	"url": "https://github.com/vapoursynth-plugin-v2.2-mac64.zip",
	"files": {
		"plugin.dylib": [
			"plugin.dylib",
			"myhash"
		]
	}
},

What about the upcoming ARM macs? => "mac-arm64": { } ? l33tmeatwad wants to compile arm plugins as well if possible.

[myrsloik]

I suppose that kind of modification would be doable. I do however think homebrew packages may be more suitable for this kind of thing since it can compile from source and already has vapoursynth in it.

[theChaosCoder]

It seems there are already some plugins which are homebrew ready https://github.com/Bl4Cc4t/homebrew-vsplugins/tree/master/Formula

Idk how hard or easy this is to setup for the user (my mac experiance is very limited). The difference here would be that no build system will be needed for plugins on the user side.

[Stefan-Olt]

I always used Vapoursynth on Linux so far, today for the first time I configured it for someone else on Windows. vsrepo is really nice, usually it's Windows where you have to find the right DLLs, while on Linux there are nice package managers. Extending vsrepo with binaries to target only one specific Linux-distribution is not very good idea. But for example the ffmpeg-build-script downloads and builds ffmpeg with all external libraries for you and it seems to work at least on macOS, Ubuntu and Debian. Why not add something like that?

My idea:

• Assume that VapourSynth was build from source and all tools and libraries required for that are available on the system.
• Add an entry "source" to the json that specifies additional dependencies (tools and libraries) and the commands to install/build the plugin
• Maintain a database similar to the json-files for the plugins how to check/install the tools in different distributions. Although there are too many build systems already in my opinion, it should be manageable, as most of the can probably easily installed using the package manager of the distribution.
• The libraries can be checked using pkg-config

The additional entry could look like this:

"source": {
				"url": "https://github.com/dubhater/vapoursynth-nnedi3/archive/v12.tar.gz",
				"hash-sha256": "235f43ef4aac04ef2f42a8c44c2c16b077754a3e403992df4b87c8c4b9e13aa5",
				"build-dependencies": {
					"libraries" : { },
					"tools": {
							"yasm": [ "yasm", "1.3.0" ],
							"autotools" : [ "autoreconf", "2.69" ]
					},
				"build-shell-commands": {
					[ "user", "vapoursynth-nnedi3-12", "./autogen.sh" ],
					[ "user", "vapoursynth-nnedi3-12", "./configure --libdir=$VSPLUGINS" ],
					[ "user", "vapoursynth-nnedi3-12", "make" ],
					[ "root", "vapoursynth-nnedi3-12", "make install" ]
				}
}

For yasm and autotools there would be additional files how to check and install those on different distributions. So if you're installing some plugin with a lot of depedencies, it will first check if you got all tools and libraries for all plug-ins to build and ask if you want them installed on your system using the package manager (like apt-get) and after that build/install all the plug-ins.
This will probaly not work everywhere from the start, but should be flexible enough to be updated to support more distributions and tools when needed.

This would of great benefit, especially since vapoursynth-plugins is not actively maintained (there seems to be a fork with some activity) and is mostly outdated and at some points rather sub-optimal (the script for building the internal ffmpeg not only uses an old version, it uses the build option "--disable-asm", no wonder Vapoursynth was so slow when reading H.264/H.265 files).

What do you think?

Best regards
Stefan

[Stefan-Olt]

I had a look at the source and noticed the code is Windows-specific in several places, for example it assumes win64 whenever you have more than 4 GiB virtual memory or for finding the vapoursynth folder.
So, IMHO to support Linux/macOS this could be a way in small steps:

1. Separate Windows-specific code into their own functions and ensure they are only called when running on Windows
2. Add a new platform posix (if separating of Mac/Linux is needed at some point sub-platforms could be introduced like posix-macos-aarch64) next to win32 and win64
3. Write posix equivalent to Windows helper functions
4. Introduce script-based plugins support for posix (for installing havsfunc etc.)
5. Add source code downloading/unpacking for posix platform
6. Add support functions for build support (finding correct directories etc.)
7. Basic building support
8. Add build dependency checking
9. Add build dependency installing

I think this are reasonable small steps.

[anon00000000]

https://wiki.gentoo.org/wiki/Project:Prefix + https://github.com/4re/vapoursynth-portage works everywhere