TODO 3: Build system

[nathanjhood]

• CMake Presets #141
• make dep #142
• fix versioning
  • investigate pushing git tags to cut releases automatically #300
  • use STONEYVCV_VERSION <= 20001000.... instead of *_VERSION_MAJOR/MINOR/etc #385
  • use git rev-parse HEAD to generate STONEYVCV_BUILDNUMBER and/or STONEYVCV_VERSION_TWEAK #315
• Better usage of 'EXPERIMENTAL' flag #134
• create CMake Object Libraries with correct dependency order; link plugin target to them #89
• CMakeRC for embedding some resources? #216
• abstract some complex CMake into local helper Modules #387

[nathanjhood]

Problem

Building and installing the plugin via the Makefile with make install etc currently still requires a fresh, unmodified copy of the Rack SDK, in order to obtain a plugin.mk with headers and libRack nearby.

I'm really hesitant to break away from the Rack SDK's build system, since we never know what changes might come in the future, which may become a requirement for building Rack plugins. If we break away, we will have to monitor this and maintain any required changes to our code. On the other hand, if we stay plugged in to the Rack SDK build system, we automatically (invisibly) stay aligned.

The biggest problem here, the only one I'm currently unsure how best to resolve, is the command make and the header file dependencies that we're otherwise resolving using vcpkg - such as StoneyDSP, CMakeRC, and such forth.

I can't seem to find any suggestions on the right way to submit new modules to the library; the suggestion is to just make a PR... I assume they want some build instructions too, or perhaps they really expect to just run one of their standard Makefile commands like make dist and it be the plugin dev's responsibility to ensure this gives the correct output?

Another solution which is probably more technically expensive, is to write a new plugin.mk for our vcpkg Rack SDK distro... but we'd also have to port arch.mk and more. It would be a smelly job, deciding which things to "fix" and which things to just copy wholesale - which I don't want to do at all, see: unknown future changes - which circles back to breaking away from plugin.mk, which ironically leads to the same issues.

Disclaimer: I also want to maintain the Makefile workflow, because CMake is not a standard requirement of a plugin project (although it is in the developer requirements list). I really want to try to keep some familiarity around for visitors of a non-CMake persuasion, which is likely to be a large majority of Rack plugin devs, it seems, since Make and not CMake is the chosen build system of the SDK.

I believe I need to make a Makefile target for vcpkg itself; some sort of shell test to see if the user has vcpkg in their path (and/or a VCPKG_ROOT with a vcpkg executable in it), and if not found, do a git fetch of vcpkg (submodule update?), and run the bootstrap script found in the vcpkg repo, set VCPKG_ROOT, and then finally append vcpkg to PATH (or prefix all vcpkg calls with a VCPKG_ROOT).

The one hindrance will be that I cannot seem to append any dependencies to the Makefile ALL target, thus I will have to explicitly tell visitors and the Users Library maintainers run a make configure or make dep first.... or, again, we could do some shell test to see if the project was configured or not....

Whatever solution is taken, it is important that the Makefile knows how to acquire and bootstrap vcpkg, to ensure that our plugin is buildable with the Rack Toolchain....

[nathanjhood]

Suggestion

To recap and attempt to formulate an idea:

When a user runs make on StoneyVCV, our Makefile should:

• do a check to see if the CMake project has already been configured (CMake configure command with no --fresh arg?)
• If not already configured, do a check to see if VCPKG_ROOT is set and a vcpkg executable exists
• If the above fails, fetch vcpkg from GitHub (to where?) and run the bootsrap script, then set VCPKG_ROOT
• If all the above was ok, configure CMake project to acquire vcpkg package dependencies
• Once we have the above step completed, we should be able to allow make to proceed as before, with the vcpkg directories include and lib added to the corresponding compiler and linker flag variables

In order to facilitate those first two steps, it makes me wonder if the vcpkg acquiring should be done on the CMake side instead....

[nathanjhood]

Suggestion

To recap and attempt to formulate an idea:

When a user runs make on StoneyVCV, our Makefile should:

• do a check to see if the CMake project has already been configured (CMake configure command with no --fresh arg?)
• If not already configured, do a check to see if VCPKG_ROOT is set and a vcpkg executable exists
• If the above fails, fetch vcpkg from GitHub (to where?) and run the bootsrap script, then set VCPKG_ROOT
• If all the above was ok, configure CMake project to acquire vcpkg package dependencies
• Once we have the above step completed, we should be able to allow make to proceed as before, with the vcpkg directories include and lib added to the corresponding compiler and linker flag variables

In order to facilitate those first two steps, it makes me wonder if the vcpkg acquiring should be done on the CMake side instead....

All of this is done and on prod; probably needs refining, though.