Use clap::helpers::Host

[Trinitou]

This is how I think clap::helpers::Host would be used for clap-wrapper

If considering merging, please make sure that before

• Some more work on PluginProxy clap-helpers#27 has been merged (contains a build fix when using clap-helpers)
• Host helper C++ class clap-helpers#24 has been merged
• include clap-helpers using the same pattern as guarantee_clap in base_sdks.cmake
  • don't forget to remove the copies!

[Trinitou]

is this a problem, @baconpaul ?
Actually I'd like to use a version tag / branch here (instead of commit hash) but we do not have that for clap-helpers yet

[defiantnerd]

I am not sure if we should include this. The clap-wrapper solves specific problems by "providing the truth" to remove the impedance mismatch between the different plugin standards, like threading models. So checking for those is kind of unnecessary.

Also, it adds another dependency which is something I wanted to avoid: only the SDKs that the wrapper is being built for should be the only ones needed.

I am more in favor to follow the path for the injector plugin to check CLAP conformity between wrapper and target plugin.

[Trinitou]

I am not sure if we should include this. The clap-wrapper solves specific problems by "providing the truth" to remove the impedance mismatch between the different plugin standards, like threading models. So checking for those is kind of unnecessary.

If we would set CheckingLevel to None, those would be gone basically gone. What would remain then? Just the basic C++ wrapper class around clap_host + all clap_host_s. I think it still would be beneficial even without any checks as the clap-helpers would be the place where new extensions will be added in the future. Then overriding the methods in clap-wrapper will be very fast to do + we can reuse this kind of C-to-C++ wrapping work instead of redoing it for every project again. Also I think it's good to have the clap-wrapper as a kind of standard/example user of clap-helpers who brings in certain requirements/goals for clap-helpers to the table (being zero-overhead at minimum checking level, easy to include, etc.).
So I think both clap-wrapper and clap-helpers could benefit from it. But maybe that's not enough?

Also, it adds another dependency which is something I wanted to avoid: only the SDKs that the wrapper is being built for should be the only ones needed.

Yeah the dependency part is the one I'm also most sceptical about myself. At least @baconpaul has done a great job of leveling-up the clap-helpers CMakeLists.txt so it should now be much more straightforward to have the helpers always in sync with the desired clap-version. (the only missing piece of the puzzle there is the version tag/branch on clap-helpers which already wrote about above)

I am more in favor to follow the path for the injector plugin to check CLAP conformity between wrapper and target plugin.

As already written, I'd be OK with setting CheckingLevel to None. The question is whether the benefits are enough to convince you to add another dependency. Feel free to do whatever you think is the best of course. In the end it's just a proposal.

[Trinitou]

Now I set the CheckingLevel to None

[Trinitou]

@defiantnerd please have look into #177 -> there I now condensed the full idea of using clap-helpers in clap-wrapper