search

AviSynth / AviSynthPlus

AviSynth with improvements
http://avs-plus.net
963 stars 73 forks source link

Use system installs of DevIL and SoundTouch on all platforms, remove in-tree binaries/code #378

Open qyot27 opened 9 months ago

qyot27 commented 9 months ago

I managed to finally test this on Windows as opposed to just on Linux and macOS (for DevIL), and to properly hook up pkg-config for SoundTouch to be able to use it from the system.

This let me run off builds using the current git HEAD of both DevIL and SoundTouch, instead of it being pegged to a particular version (not that DevIL mattered too much; v1.8.0's DLLs as provided upsteam can be swapped in against our builds that use the 1.7.8 in the tree).

Additionally, it means allowing ImageSeq to link against a static build of DevIL, removing the need to even install DevIL.dll at all: https://www.mediafire.com/file/i08vu91xvj4715l/static_plugs.7z/file

pinterf commented 8 months ago

Sorry, I'm going to check it later in deep. But some questions till then.

I understand that packages work well in linux and mingw environment, but I cannot use them on my plain Windows + Visual Studio? At least the build documentation must be changed accordingly. E.g. fetch X and Y from this and that git repo, build with VS2022 howto, etc. - it's not 100% clear to me right now. What are the prequisites that cmake detect (and build for proper bitness/CPU architecture?) them?

How would the installer behave? I suppose it won't remove the existing DevIL.dll even if it's not needed anymore.

qyot27 commented 8 months ago

I understand that packages work well in linux and mingw environment, but I cannot use them on my plain Windows + Visual Studio? At least the build documentation must be changed accordingly. E.g. fetch X and Y from this and that git repo, build with VS2022 howto, etc. - it's not 100% clear to me right now. What are the prequisites that cmake detect (and build for proper bitness/CPU architecture?) them?

A pkg-config or pkgconf installed by MSys2 can be used for this if you've added its bin directory to the Windows %PATH%. That's how my setup was configured with VS 2019. I'm fairly sure I was even using it directly from Windows Terminal and didn't even have to launch MSys2 from inside the VS Command Prompt(s) (although I think I did anyway just so I could do mass directory creation with mkdir -p build/{amd64,aarch64,i686}).

Luckily, SoundTouch, DevIL, and even most of DevIL's dependencies already use CMake or at least offer it as an alternative option so that MSVC builds can happen relatively easily.

Structure-wise, I realized that using --target install could override any MSVC-ish default installation paths, so everything could go into one sane place that everything else can refer to, and that it just uses the standard *nix directory hierarchy. If -DCMAKE_INSTALL_PREFIX=E:/devil_deps, then

E:/devil_deps/
              bin/
              include/
              lib/
              lib/cmake/
              lib/pkgconfig/
              share/

The only attention I had to pay to architecture was to launch the appropriate VS Prompt. The Native Tools prompts for x64 and x86, and the cross prompt for ARM64 (as the only Windows on Arm thing I've bothered to set up is a flash drive that I can boot on the Raspberry Pi 4...which is only barely usable as a proof-of-concept; I haven't tried getting it set up on the M1 Mac Mini, which from what I understand, running it under a VM on Apple hardware actually gives it enough headroom to be usable).

Since Windows on Arm is still such a niche target, and AFAIK no third-party plugins other than the FFMS2 C++-plugin builds I've run off even exist for it yet, maybe we can actually go ahead and try to eliminate the C++ ABI conflict on ARM by ifdeffing extern "C" onto the C++ interface if we're not on x86/x64. That'll require more experimentation to see if that's viable.

How would the installer behave? I suppose it won't remove the existing DevIL.dll even if it's not needed anymore. Correct, since the only thing it would try to do is install DevIL.dll, and similar to some of the other toggleable selections in the installer script, whether DevIL.dll exists as a separate library at all can be enabled or disabled by just commenting it out/back in.

Even though I might provide ImageSeq as a statically linked plugin, the way the detection works means that the user could just as easily opt for a standard shared library just like it is now (and arguably, that's still the easier route, since the upstream project has their SDK package which assumes you'll have the .dll lying around, and removes the hassle of trying to compile DevIL's dependency chain).

[Examples in next post]

qyot27 commented 8 months ago

So for instance with SoundTouch, launch the VS Command Prompt for x64, launch MSys2's MinGW64 shell from inside the VS Prompt (for the mkdir and nproc stuff), and then (assuming we were using E:\Documents_C\mpv-build-deps as the source download area):

cd /e/Documents_C/mpv-build-deps && \
git clone https://codeberg.org/soundtouch/soundtouch && \
mkdir -p soundtouch/soundtouch-build/{amd64,aarch64,i686}

cd /e/Documents_C/mpv-build-deps/soundtouch/soundtouch-build/amd64 && \
cmake ../../ -G "Visual Studio 16 2019" -T "v141_xp" -DCMAKE_INSTALL_PREFIX=E:/devil_build_deps/amd64 && \
cmake --build . --config Release -j $(nproc) --target install

and it'll install the MSVC-built libraries to E:\devil_deps\amd64. Then for AviSynth+:

cd /e/Documents_C/mpv-build-deps/AviSynthPlus/avisynth-build/amd64 && \
    cmake ../../  -G "Visual Studio 16 2019" -T "v141_xp" -DCMAKE_INSTALL_PREFIX=E:/avisynth_build/amd64 \
    -DBUILD_DIRECTSHOWSOURCE:bool=on -DWINXP_SUPPORT:bool=on -DCMAKE_PREFIX_PATH=E:/devil_build_deps/amd64  && \
cmake --build . --config RelWithDebInfo -j $(nproc) --target install

-DCMAKE_PREFIX_PATH is used to set where CMake should look for both CMake files and the pkg-config subdirectory so that pkg-config can do its work, so it should pick up on SoundTouch being there and just enable it.

For DevIL, if you want to use the SDK provided by upstream (DevIL-Windows-SDK-1.8.0.zip), then you need to either move the .lib files out of their subdirectories and into the main lib/ directory, or use -DIL_LIBRARIES and explicitly point at the location of DevIL.lib and ILU.lib - -DIL_LIBRARIES="/path/to/DevIL-Windows-SDK-1.8.0/DevIL Windows SDK/lib/x64/Release/DevIL.lib;/path/to/DevIL-Windows-SDK-1.8.0/DevIL Windows SDK/lib/x64/Release/ILU.lib". If you want to produce the fully-static DevIL.lib so that ImageSeq links to that*, is where it gets tricky and involved: most of DevIL's dependencies are only 1 or 2 levels deep, except for libtiff, because libtiff can go 3 or even 4 levels deep with its dependencies. It was trying to get all of that to play nice that took time to work out in my notes.

DevIL's SDK download provides .libs in Release/ and unicode/Release/ under x64, although I don't know if that makes a difference for us; the path reconciliation stuff we care about might only be restricted to ImageSeq itself and it won't care about DevIL being Unicode or not.

qyot27 commented 7 months ago

I've added a guide to the documentation that covers the process of building current SoundTouch and the DevIL dependency chain, and what needs to be done to use either the prebuilt DevIL SDK with these changes or to use the locally-built DevIL.

The resulting build would be basically identical to this: https://www.mediafire.com/file/3hc90l24itcuhv4/avisynth%252B_r4069.7z/file