free-audio / clap

Audio Plugin API
https://cleveraudio.org/
MIT License
1.77k stars 100 forks source link

entry.h: Clarify recursion stopping points #113

Closed baconpaul closed 2 years ago

baconpaul commented 2 years ago

Clarify the .clap file type on OS as bundle vs directory and subsequent host stopping behavior per discussion in https://github.com/free-audio/clap/discussions/102

abique commented 2 years ago

I'm not sure if the text regarding traversing directories actually helps. It makes the documentation harder to understand, while I'm not sure if it brings much to the table.

I believe that the rule is already clear:

abique commented 2 years ago

Did you stumble upon a problem that required to further specify this behavior?

robbert-vdh commented 2 years ago

Did you stumble upon a problem that required to further specify this behavior?

In #102 there was some confusion about whether or not ~/.clap/foo.clap/foo/bar/foo.clap or ~/.clap/foo.clap/Contents/x86_64-linux/foo.clap was a legal directory structure. I don't see why there would be any reason to believe it isn't or any any host could try to dlopen() that entire foo.clap directory (since that simply won't happen in any directory walking implementation), but that's what triggered this.

baconpaul commented 2 years ago

Did you stumble upon a problem that required to further specify this behavior?

yes

we accidentally installed surge so that it installed in "Surge XT.clap/Surge XT.clap" and bitwig didn't scan it in windows

robbert-vdh commented 2 years ago

we accidentally installed surge so that it installed in "Surge XT.clap/Surge XT.clap" and bitwig didn't scan it in windows

Has that been reported on the interop tracker yet?

baconpaul commented 2 years ago

we accidentally installed surge so that it installed in "Surge XT.clap/Surge XT.clap" and bitwig didn't scan it in windows

Has that been reported on the interop tracker yet?

we fixed surge so i didn't think to report it on interoperability. i will.