Just like it already did for the VST3 library. This information was not
necessary for the functionality of yabridgectl, but it does look nicer
this way.
With the `ghc::filesystem` dependency from the previous commit. If we
can replace the rest of the Boost.Filesystem dependency then we can get
rid the one nasty runtime dependency we have, and it will make
implementing the chainloading simpler since can reuse more code without
bringing in Boost.
This reverts commit eee3d218c1.
This sounded good in theory, but in practice this doesn't work, because
there's no real way to find the matching .dll file form an .so file
without brute forcing it using a bunch of directory listings.
Hopefully this shouldn't be needed, but I didn't realize we only parsed
lower case file names. Wouldn't be surprised if some installer ends up
creating an uppercased `.DLL` file.
This is a bit of a mess (which is also why I kept procrastinating on
this), since we also need to keep symlinks, trailing slashes, and weird
unnormalized paths into account.
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.
Robbert van der Helm