Make "pluginval as a dependency" a 1st class citizen

[sudara]

Jotting this down to keep track of me looking into this. The idea is to have pluginval as a project dependency vs. an external tool.

To be clear (also for GPL licensing reasons), pluginval wouldn't be linked to the plugin and shipped to end users. It's just used locally when debugging.

The benefits are:

• Full call stack. Right now when debugging via pluginval, one only gets the exact line of code in my project vs. the full stacktrace. Not sure if there's another way to get more of call stack, but it impedes investigation when there's an error.
• Less friction to start pluginval. Build the target from within the IDE and pluginval runs against the project. No need to open another project, pull changes, build, etc.
• Easy ability to set breakpoints in the main project
• I could add pluginval to pamplejuce so everyone starting out gets 1-click pluginval.

@eyalamirmusic and I merged some initial work to enable this a while back.
#78

He has a sample plugin showing how he added a custom target for running:

add_custom_target(${BaseTargetName}_Pluginval
        COMMAND
        pluginval
        --validate
        --strictness-level 10
        ${artefact}
        DEPENDS ${BaseTargetName}_VST3 pluginval
        VERBATIM)

• Confirm Eyal's setup is happy, or if more changes needed
• Check Windows vs. Mac — possible to do AU on Mac vs. VST3 Windows?
• Evaluate CI workflow (in particular, pluginval's copy of JUCE isn't wanted/needed when its a dependency, can we somehow not recurse submodules for this particular repo? Or could we move pluginval's version of juce to FetchContent/CPM and be conditional on the cmake variable? Or are we just happy to suck down an extra copy of JUCE we don't want)
• Update README with instructions

[sudara]

Ok, this runs pluginval, but the command doesn't run in the debugger, the process just exits on fail saying "ninja: failed to build"

add_subdirectory("modules/pluginval")

# Use our version of JUCE, not pluginval's
# This is brittle, the string has to match perfectly
set(PLUGINVAL_FETCH_JUCE OFF CACHE BOOL "Fetch JUCE along with PluginVal" FORCE)

get_target_property(artefact ${PROJECT_NAME}_VST3 JUCE_PLUGIN_ARTEFACT_FILE)

add_custom_target(${PROJECT_NAME}_Pluginval
        COMMAND
        pluginval
        --strictness-level 10
        --validate
        ${artefact}
        DEPENDS ${PROJECT_NAME}_VST3 pluginval
        VERBATIM)

This just adds a pluginval target (opens the Pluginval GUI), which is perfect for local dev:

add_custom_target(${PROJECT_NAME}_Pluginval
        DEPENDS ${PROJECT_NAME}_VST3 pluginval
        VERBATIM)

However, on my current error on Windows, with Validate In Process checked, I still don't get any more of the call stack!

[sudara]

Ok, that particular error I was dealing with was behaving strangely in the way the program aborted.

The next issue is hitting a jassert in JUCE.

When running pluginval standalone, it is quite unhelpful, showing only pluginval and juce code in the call stack.

When running pluginval as a target in my plugin project, I get a nice call stack all the way through my app code:

So far I'm sold cautiously optimistic that this makes debugging much easier.

[drowaudio]

Sounds very cool!