TODO 1: Deps

[nathanjhood]

• WIP: Refactor codebase to seperate plugin, library, test, and external vendor code #15
• WIP: dependency injection with vcpkg and CMake #21
• cleanup VCVRack CMake install target directories #90
• add a pkgconfig file for Rack-SDK #187
• Make sub-targets for each dep; rack-sdk::dep::openssl, and so forth, each with their own FILESET and correct dep linkages #329
• add more SDK versions to the vcpkg local filesystem registry
• Make CMake API helper functions for creating VCV Rack plugin, modules, and more #121
• vcpkg as a submodule with Makefile support #330
• migrate local StoneyDSP to remote
• migrate local vcpkg-registry to remote

[nathanjhood]

Idea 💡 vcpkg as a submodule with Makefile support

Easy one. Before I can truly commit to my buildsystem, I need to ensure Makefile support. To accomplish this, I need to ensure that the Makefile can find my dependencies of StoneyDSP and Catch2.

In which case, I can just add vcpkg as a submodule under dep/vcpkg (I already renamed the old dir in that location to dep/vcpkg-registry to allow this), and create the following Makefile rules:

• git submodule update init recursively
• bootstrap vcpkg if required using it's script(s) for the purpose
• set VCPKG_ROOT to dep/vcpkg
• configure CMake with -DCMAKE_TOOLCHAIN_FILE..., i.e., using the CMake Presets I already wrote

This seems pretty straightforward. I'm tempted to use my own fork of vcpkg, as I could in theory add my custom ports and triplets to a branch on that fork. Alternatively, I've already got a repo in this org called vcpkg-registry which unsurprisingly somewhat resembles the filesystem registry I created in this project - I'd need to add that repo to my vcpkg configuration JSON file...

I'm slightly more in favour of keeping the registry separate from the vcpkg repo; it will be easier to maintain, and easier to share, the registry as a vcpkg config thing... i.e., with the Rack community.