design ideal module source structure for app/plugin developers

atsushieno / aap-juce

AAP (Audio Plugins For Android) JUCE integration.

GNU General Public License v3.0

15 stars 1 forks source link

design ideal module source structure for app/plugin developers #7

Closed atsushieno closed 3 years ago

atsushieno commented 4 years ago

The current state of aap-juce support is a big hack and not practically ready for external developers. We have to restructure the entire repo to ease porting.

JUCE-AAP modules: copy AAP header files directly under the module sources so that any subsequent huge checkout becomes unnecessary.
distribute androidaudioplugin.aar and prebuilt native dependencies via Maven so that at least they can be simply added as a Maven dependencies, along with those header files above. (It is rather an issue in android-audio-plugin-framework.)

Emscripten support is another issue that needs a lot more effort, so it can be skipped for now.

atsushieno commented 4 years ago

And Google has already achieved exactly what I described above in the very latest AGP. https://google.github.io/prefab/build-systems.html

atsushieno commented 4 years ago

After couple of attempt to use ndkports, I figured ndkports is still no-go. Current builds are based on Cerbero, which is <10x prepared than ndkports. And cerbero alright, it's just "unsupported" for any non-GStreamer projects.

Aside that, packaging things based on prefab format is doable manually.

atsushieno commented 4 years ago

And JUCE is going to support native CMake build, which is a game changer. https://forum.juce.com/t/native-built-in-cmake-support-in-juce/38700

atsushieno commented 4 years ago

Some notes:

JUCE6 CMake support requires cmake 3.15 for audio plugins (according to their README for CMake example)
We can specify custom CMake setup using local.properties (explained on an Android developer doc)
We need additional CMake setup for CI...

atsushieno commented 4 years ago

This almost overlaps https://github.com/atsushieno/aap-juce/issues/15, but we'd leave it as a separate issue (it in theory is).

atsushieno commented 4 years ago

We can specify custom CMake setup using local.properties (explained on an Android developer doc)

This item, which was actually mentioned by a JUCE developer, turned out to not apply here. Whatever local.properties can point to is only the directory that Google ships as part of Android SDK components. Standard CMake distributions from Kitware has completely different set of files and they are not simply interoperable.

atsushieno commented 3 years ago

There has been a lot of progress after the last comment (which I believe is not really correct). There are two key points in this issue:

reference androidaudioplugin.aar from maven -> done in android-audio-plugin-framework, still have to build locally, but now it pushes to mavenLocal(). Still have to submodule android-audio-plugin-framework because prefab is still no-go, but that can be made optional (copy aap headers, minor issue).
support CMake builds -> issue #15
split repository for each app so that other developers can simply submodule this repo and build their own -> issue #20

Now that they are logged and/or achieved, this issue can be closed.