iOS and Android Support
Opened this issue · 8 comments
Hi, I got here from this JUCE forum post:
https://forum.juce.com/t/introducing-juce-cmake-build-your-juce-projects-using-cmake/22717
Its quite old so I'm just wondering, are iOS and Android still not supported? If not what is the challenge?
Hi,
Thank you for your interest in FRUT!
The README lists the supported exporter targets from Projucer, and indeed FRUT still doesn't support "Xcode (iOS)" nor "Android".
For iOS, I simply can't do the work alone. I don't own a computer that runs macOS and I don't own an iPhone or iPad. Also, there are some settings that Projucer writes in the Xcode project (for instance SystemCapabilities), which CMake doesn't support. However, it doesn't mean that it's impossible to add some iOS support to FRUT. I have enough experience with the "Xcode (MacOSX)" exporter and enough knowledge about the Projucer code that I could implement some experimental iOS support "blindly". I just need to be sure that someone will be keen on testing my broken implementation and will report the issues.
For Android, it would be a bit simpler, since Android Studio is available on Linux and Windows, and I do own a smartphone that runs Android. However, I don't have any experience building for mobile, so it will require a fair amount of work from my side (especially considering all the changes on the "Android" exporter in Projucer since JUCE 4.2.0). Again, it is not impossible to do. All I need to get started are people like you who are showing their interest and will actually use what I've worked on.
If you're interested in helping me by testing some experimental support of the "Xcode (iOS)" and "Android" exporters in FRUT, let me know!
Hi @McMartin that makes sense. if I do end up going with JUCE for an upcoming project I will help out.
One other thing...I haven't actually tried your cmake code, but if I read it right it seems to need a Projucer file to work off. My hope was that a CMake JUCE build could do away with the need to run Projucer at all. I realize some decisions need to be made like whether its going to be an AudioUnit or something similar, but couldn't those just be CMAKE variables or flags of some kind?
The only reason was that I used Projucer a few years ago and really didn't like working in it at all and would rather just dial in everything myself in my CMakeLists.txt file.
if I do end up going with JUCE for an upcoming project I will help out.
Great! Thanks a lot!
it seems to need a Projucer file to work off.
Currently, FRUT only provides Reprojucer.cmake, which (as its name suggests) reproduces the behavior of Projucer. So having an existing .jucer project file makes things easier. You can use Jucer2Reprojucer to convert this .jucer file into a read-to-use CMakeLists.txt file. However, a .jucer file is not required to use Reprojucer.cmake. It will take you a bit more time to get started (since you won't benefit from Jucer2Reprojucer), but you can easily copy-paste from the CMakeLists.txt files that are in the generated/ folder. And I'm always happy to help!
In the (near) future, FRUT will also provide FindJUCE.cmake, which will allow you to build JUCE projects in a "pure" CMake way (using find_package(JUCE REQUIRED COMPONENTS ...) and then using almost only standard CMake commands). But in the meantime, FRUT only has Reprojucer.cmake to offer.
Awesome, sounds good to me. Sounds like if I want to go through the hard work I can ;). Thaks for working on this. I'll check in again as I mentioned if I end up going the JUCE route.
What is still missing to reach FindJUCE.cmake to be ready?
@Pwera I'm sorry for the very late reply. Unfortunately, there is still quite a lot missing to reach a functional FindJUCE.cmake. I have a WIP branch with a prototype, but nothing that I would merge into FRUT now or very soon. I'm currently working on turning this prototype into the real thing, but I can't give any ETA yet.
I'm sorry for hijacking this... Concerning the need for Projucer, does this mean that once I turned the jucer file into a CMakeList I can somehow treat it as a standard CMakeList and manually add e.g. new source files or targets?