If pruning results in a directory becoming empty, then we should remove
that directory. This approach won't touch any directories that we aren't
pruning from.
This commit does a couple of things since the refactoring made it
difficult to split these things up:
- The counts for managed and new plugins are now always correct, even
when plugin directory A contains a symlink to plugin directory B.
- Orphan files will now be pruned from managed VST3 directories, making
switching between different architectures easier. (the previous
approach involved nuking the entire bundle, which of course has a
bunch of downsides)
We should be a bit more clever about this. This approach would mean that
the plugin would be rescanned every time, since the whole 'don't
reinstall plugins if that wouldn't change anything' thing no longer
works with this approach.
We would completely remove VST3 bundles that yabridgectl does not know
about anymore, but we would not remove leftover files within bundles.
This could otherwise cause issues when messing with 32-bit and 64-bit
versions of plugins or yabridge itself.
When yabridgectl sets up both a VST3 bundle containing both a 32-bit and
a 64-bit plugin. The libyabridge.so file already existed, so the
reported number was always off.
VST2 and VST3 plugins are now handled in the same way, reducing a bit of
duplication. We now also store the architecture for VST2 plugins so we
can show that in `yabridgectl status` later.
This should make the output look much less cluttered since most of the
output would consist of the same path prefix being repeated over and
over again.
The plugin location now also always ends with a trailing slash for
consistency's sake. I don't think Rust's Path has a way to normalize the
paths without also resolving symlinks.
This is still missing checks for removing leftover files, symlinks for
resources and presets, and a way to differentiate between plugins with
the same name from different prefixes.
This will probably solve the last common setup issue. Starting Wine can
take a second so this check is only repeated when either Wine or
yabridge get updated.
The path check should only take a few milliseconds to run, but checking
whether yabridge-host.exe runs correctly could take over a second when
wineserver isn't already running in the background.
When creating copies with yabridgectl. This should at least give an
advance warning that some additional steps are required when first
setting up yabridge.
Robbert van der Helm