Update DPF to pull in fix for plugin GUI on some hosts.

[Justin-Hoffman]

This updates the DPF commit hash to a recent develop branch version.

It fixes a crash in the plugin GUI that was being experienced on some hosts.

[falkTX]

the way to enable file browser is very hacky, we just need an optional arg to dpf_add_plugin
see https://github.com/DISTRHO/DPF/blob/develop/cmake/DPF-plugin.cmake#L105

[Justin-Hoffman]

the way to enable file browser is very hacky, we just need an optional arg to dpf_add_plugin see https://github.com/DISTRHO/DPF/blob/develop/cmake/DPF-plugin.cmake#L105

Copy that. Will fix. Fixed

[Justin-Hoffman]

Is the runner label "macos-11" retired? That job has been waiting for a runner for over 8 hours and I only see 12+ here:
https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners

It seems like yes, it's retired, so I've added a commit to request macos-12 for that action. I can only hope that this doesn't introduce any compatibility issues as I don't have a MacOS machine available to test this on easily.

[Justin-Hoffman]

The Mac builds hit the error that I had seen on Linux with an older DPF version:

/Users/runner/work/AIDA-X/AIDA-X/src/jucewrapper/../../modules/dpf/distrho/src/DistrhoPluginChecks.h:167:3: error: invalid build config: file browser requested but `USE_FILE_BROWSER` build option is not set
# error invalid build config: file browser requested but `USE_FILE_BROWSER` build option is not set

I'm guessing for that platform we need to do something different? Any suggestions here @falkTX ?

Edit

Reading more, I think I need to define USE_FILE_BROWSER for the juce plugin build via set_target_compile_definitions() (which already exists). I suspect the other errors like:
error: no type named 'FileBrowserOptions' in namespace 'AidaDGL'; did you mean simply 'FileBrowserOptions'
will just go away with that fix due to changes in header includes.

Edit 2

Yeah, I can trigger the same error locally if I enable the JUCE build here (which is only on by default for Mac, hence the build issue only for that build. With these last fixes I can build the JUCE plugin here locally without issue.

[falkTX]

Yeah, I can trigger the same error locally if I enable the JUCE build here (which is only on by default for Mac, hence the build issue only for that build. With these last fixes I can build the JUCE plugin here locally without issue.

I completely forgot I had done a JUCE wrapper just to get AU, hah.
It was a while ago, now DPF supports AU natively, so we can get rid of the JUCE hacks. but should be a separate PR, will need tweaks to some core files to implement it properly anyhow

[Justin-Hoffman]

And now we have:
make[2]: *** No rule to make target bin/AIDA-X.a', needed by bin/AIDA-X.component/Contents/MacOS/AIDA-X'. Stop.

Looking into it

Edit

Why define imported static libs near the top of src/jucewrapper/CMakeLists.txt to link to AIDA-X-JUCE when we can refer to the $<TARGET_FILE:AIDA-X-static> (and same for dgl-opengl) in the target_link_libraries() at the bottom of that file?

I will note that in the build log I see:

2024-12-13T19:29:28.7776030Z [ 84%] Linking CXX static library bin/AIDA-X.dylib
2024-12-13T19:29:29.2676690Z [ 85%] Built target AIDA-X-static

Note ends in .dylib, not .a.

I also see comments that suggest getting a static library at all for MacOS was a "hack" did macos-13 break your hack?
Is this not a .a but a .dylib in new MacOS?

[falkTX]

the entire juce thing is a big hack, so best to just ignore it or just outright remove it.

[Justin-Hoffman]

the entire juce thing is a big hack, so best to just ignore it or just outright remove it.

Understood. Mind approving this pipeline to see if simply specifying linked library as whatever the existing targets emit will resolve this?

If that doesn't work, or if you're not happy with this, I can also just strip the JUCE / AU build out entirely.

[falkTX]

Sure thing! can set up the AU stuff now too