clap-wrapper icon indicating copy to clipboard operation
clap-wrapper copied to clipboard

`RESOURCE_DIRECTORY` for copying verbatim into clap-first bundle

Open geraintluff opened this issue 8 months ago • 8 comments

This works for MacOS CLAP/VST3.

It should print out a warning for all other platforms, saying this option is not supported.

geraintluff avatar Apr 10 '25 15:04 geraintluff

So this basically assigns a resource directory argument to each sub target. And looks correct.

But it makes me wonder if instead, since these 93 changes will be irraitatinv for the next 14 properties. If we want to contemplate something like a cmake function which sets properties on all the wrapper generated targets based on the clap first name. Something like `set_Clapfirst_Properties(target t formats f1 f2 properties a avail b Bval)112th

then we could use that after make clap first to markup the targets.

see what I mean?

baconpaul avatar Apr 10 '25 17:04 baconpaul

You'd still need logic to check for those properties though, wouldn't you? And I suspect there might not be much shared logic for how those arguments are actually used.

Even in just those two formats (CLAP/VST3 for Apple), I've already had to special-case VST3 bundles because it can optionally include the .clap itself inside the bundle (in which case resources should already be inside the CLAP).

geraintluff avatar Apr 10 '25 19:04 geraintluff

I do see how setting properties (on the _impl static library?) would mean new settings propagate nicely to all the functions.

I feel that's a separate (and substantial!) refactor though, not for this PR.

geraintluff avatar Apr 10 '25 19:04 geraintluff

Nan I was thinking of a new function which sets on the endpoints. ‘let me peek tomorrow and if it is a nightmare we can just merge this. That ok with you?

baconpaul avatar Apr 10 '25 23:04 baconpaul

Sounds great. 😄

A note/question: because there are custom copying commands for both RESOURCE_DIRECTORY and COPY_AFTER_BUILD, there are two (conditional) calls to add_custom_command(). This worked OK when I tested it, but it also smells like a race condition.

geraintluff avatar Apr 11 '25 09:04 geraintluff

I thought (and it’s my experience so far that it is true that) cmake reliably orders them in parse order so we should be fine but a test in ci would be great

baconpaul avatar Apr 11 '25 18:04 baconpaul

@baconpaul Hey - did you manage to take a look at this?

geraintluff avatar Jun 24 '25 22:06 geraintluff

Oh I'm so sorry

I like my bigger idea but won't get to it soon so lets go with my original instinct of 'rebase, pass CI, and merge'

sound good?

baconpaul avatar Jul 18 '25 16:07 baconpaul

@baconpaul Bump

geraintluff avatar Nov 14 '25 09:11 geraintluff

Oh damnit I'm so sorry

I was about to merge it and on a review saw one thing not about RESOURCE_CIRECTORY which I don't think belongs in this commit and looks wrong.

The resource directory only changes I'm happy to merge even though I think there's a more general blah blah way we could do but since we haven't lets get this feature in your hands now.

baconpaul avatar Nov 14 '25 15:11 baconpaul

@baconpaul Thanks for catching that - I've removed the extra commit.

geraintluff avatar Nov 17 '25 20:11 geraintluff