atsushieno
commented
3 years ago The actual problem here is not LV2 toolkits. Building lv2 toolkits from source it lightweight. Building mda-lv2 binaries is somewhat cumbersome. And it hardly happens that we have to debug those proof-of-concept plugin ports. And if we build lv2 toolkits within the repo while building aap-mda-lv2 outside, it's going to be annoying. But - should aap-mda-lv2 also go outside the repo? That means this repo has almost no good dogfood (except for app-ayumi, which is too trivial).
I have been restructuring LV2 deps these days, and it is quite annoying. The first thing I did was repository split. All those heavyweight plugins (sfizz, guitarix, fluidsynth) are now gone and the build becomes much faster.
Then I tacked LV2 toolkit updates. It was only supposed to bump versions, but it actually involves non-trivial merge conflicts, and it indeed regressed. Things that built didn't work. mda-lv2 plugins started to crash.
I stared debugging it, but it was known as non-intuitive steps from the past experience, because of binary deps split. I recorded history of the steps, but there was also non-trivial updates and the source code diff didn't work as it was. I spent time to make it up to date, and now it is debuggable. I could diagnose the changes in serd and lilv, and aap-mda-lv2 now works.
Now I have to revert all those local debugging bits, and they will be lost. It is quite annoying. The debugging experience was much better with sources. When it is hard for me to debug, it is almost impossible to anyone else.
Should I switch to "submodule lv2 toolkits" strategy? Build takes more time (like 2 minutes every time) and that is imposed on any aap-lv2-based plugins, but they would also benefit from the debuggability.