Open qyot27 opened 1 year ago
Added a couple more commits to make the VapourSynth plugin only be built if VapourSynth is installed, since the same situation could arise in reverse, and moving to installing the library in the main libdir
and symlinking into the corresponding AviSynth or VapourSynth plugin autoload directories if those backends have been detected and built.
Obviously this raises the question of 'what if neither are installed?', in which case you'll have the plain library with no plugin interfaces installed in libdir
, and no symlinks created. That part mostly comes down to whether that's a desired configuration, but otherwise we'd have duplicate copies of the library getting installed in two different directories in libdir
.
The only foreseeable issue I know of is if it gets installed with one of the two interfaces, and then gets rebuilt later without that same interface, because the symlink would still exist in the autoload dir but point to an non-functional source library. Which circles back around to whether it should install duplicate copies or not.
Awesome work, @qyot27. Thank you!
Basically also a fix for https://github.com/pinterf/KNLMeansCL/issues/2, because the AviSynth plugin lacked the GCC visibility thing that needs to be adjusted for vs. Windows'
__declspec(dllexport)
. That bit was copied from LSMASHSource.Assumes that *nix users are going to want to use the installed (currently v9) headers, which additionally caused issues with the
#ìfdef __AVISYNTH_8_H__
in NLMAvisynth.{h|cpp}. I'll admit that that commit is a complete hack; it probably should have a better version detection setup. Feel free to replace that with a better option if you want. Since anyone compiling 3.7.2 from source is going to get v9 headers, and virtually all of the distros that package AviSynth+ ship 3.7.2 or would otherwise rely on users building it themselves, I'd be willing to bet almost no-one is going to have pre-v8 headers on their system to screw it up.Using this patchset I was able to confirm that 1) the plugin works on Linux, but also 2) the GPU's OpenCL functionality is in fact being used (although intel_gpu_top just has it shoved under 'unknown', but without KNLMeansCL in the script, there is no usage under that category; with it in the script, and trying to process an 8K video, it's sitting around 17% or so).