Yes, a readme that should not be read! I guess it's mostly there for
documentation's sake, because you probably shouldn't need any of
yabridgectl's functionality that's not outlined in the main readme.
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.
Since there isn't any public documentation on VST2, I saw JUCE and a
couple of other plugins and bridges use this, but they all redefined the
symbol to`main`.
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.
And print a more descriptive error message instead. This is only
relevant when using a `WINELOADER` that causes `$WINELOADER --version`
to not output anything.
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.
Robbert van der Helm