Skip to content

Conversation

@geraintluff
Copy link
Contributor

This works for MacOS CLAP/VST3.

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

@baconpaul
Copy link
Collaborator

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?

@geraintluff
Copy link
Contributor Author

geraintluff commented Apr 10, 2025

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
Copy link
Contributor Author

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.

@baconpaul
Copy link
Collaborator

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?

@geraintluff
Copy link
Contributor Author

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.

@baconpaul
Copy link
Collaborator

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

@geraintluff geraintluff changed the title [WIP] RESOURCE_DIRECTORY for copying verbatim into clap-first bundle RESOURCE_DIRECTORY for copying verbatim into clap-first bundle Jun 24, 2025
@geraintluff
Copy link
Contributor Author

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

@baconpaul
Copy link
Collaborator

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?

@geraintluff
Copy link
Contributor Author

@baconpaul Bump

@baconpaul
Copy link
Collaborator

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.

@geraintluff
Copy link
Contributor Author

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

@baconpaul baconpaul merged commit 7d53a88 into free-audio:next Nov 17, 2025
24 checks passed
@geraintluff geraintluff deleted the next branch November 17, 2025 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants