so, apart from juce might make it to iPhone, what about Android?
Sadly, it doesn’t seem to be straight forward Linux, but a pretty thick layer on top.
Bruce
Well, it’d be nice, but I don’t know anything about the architecture it uses. Isn’t it all done is Java?
well yes and no.
it uses Dalvik as interpreter for bytecode, which (bytecode) in turn is generated by a java compiler. But Dalvik bytecode and java bytecode are different from what i know.
But no, 
it doesn’t seem easy to use C++. Sorry, never mind.
Bruce
At least it could be run in OpenMoko. We only need to make juce run on the ARM platform.
Indeed, I have asked a couple of times for removing the x86isms that prevented me to cross-compile Juce. If that was done, it could have a nice future on x11-based smartphone platforms.
Mickey (freesmartphone.org; funded by Openmoko, Inc.)
[quote=“mickey”]Indeed, I have asked a couple of times for removing the x86isms that prevented me to cross-compile Juce. If that was done, it could have a nice future on x11-based smartphone platforms.
Mickey (freesmartphone.org; funded by Openmoko, Inc.)[/quote]
Have you? Can you remind me which x86isms you mean…?
Oh well, as you can see at my join date, it’s been over 3 years since I last tried 
Let me try to cross-compile the latest version for armv4t and then I’ll give you an update.
Ok, here we go. First itch was hardcoded includes to /usr/include, these are interfering when cross-compiling. After patching these out, it bails out like that:
ERROR: function do_compile failed
ERROR: log data follows (/local/pkg/oe/fic-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/juce-1.46-r0/temp/log.do_compile.10609)
| NOTE: make -j5 -e MAKEFLAGS=
| ==== Regenerating Makefiles ====
| Generating GNU makefiles:
| ...JUCE
| ==== Building JUCE ====
| juce_Random.cpp
| juce_RelativeTime.cpp
| juce_Logger.cpp
| juce_Time.cpp
| juce_SystemStats.cpp
| ../../src/juce_core/basics/juce_Atomic.h: In function 'void juce::initialiseJuce_NonGUI()':
| ../../src/juce_core/basics/juce_Atomic.h:98: error: impossible constraint in 'asm'
| ../../src/juce_core/basics/juce_Atomic.h:137: error: impossible constraint in 'asm'
| ../../src/juce_core/basics/juce_DataConversions.h:52: error: impossible constraint in 'asm'
| make[1]: *** [../../bin/intermediate_linux/Debug/juce_SystemStats.o] Error 1
| make: *** [JUCE] Error 2
| FATAL: oe_runmake failedWell, if you have a look where it’s failing, you’ll see there’s a JUCE_USE_GCC_ATOMIC_INTRINSICS flag that will probably avoid that problem.
There might be a few places like that where the build system needs a tweak to cope with new platforms.
well, given the new batch of android tablets that are just coming out, having Juce on Android would be fantastic.
I’m thinking midi touch screen controllers, audio apps on the road, …
and btw, you can develop in C++ for Android, with the native SDK:
http://developer.android.com/sdk/ndk/index.html
I’m sure Juce could become one the hottest frameworks on the planet if it covers both IPhone/Pad and Android
The Native SDK is NOT for application development. It is only for library development. There are a limited number of API’s available.
I am aware of the fact that the NDK is not the mainstream way of developing for Android and there very probably will be a need for some java code to make things work
but then again, if a native version of Quake can be ported with support for audio, keyboard input, touchscreen, trackball and 3D graphics… http://code.google.com/p/kwaak3/
point taken… some java glue will be needed… especially as there is no native access to the audio api’s…
Wrapping a game like quake is pretty easy, TBH - all it needs to do is give it a buffer to draw into and forward the mouse events to it. Doing a full port of juce would involve vastly more interaction with the OS, and should ideally use the standard java classes for rendering graphics, as that’s the only way to get hardware acceleration. Plus, the native SDK is a PITA to build as it’s all processor-specific… So my feeling is that although compiling a c++ app into java bytecode is a bit of a strange thing to do, it’s probably the only way that’ll work well and be portable to any device.
There’s already a compiler called LLJVM which produces bytecode from c++, I need to experiment with it and try to figure out if it’s feasible to build such a big project that way.
Hi Jules, the LLJVM route sounds very intriguing indeed… If real-world C++ can run on a JVM while keeping reasonable performance, that would be amazing. Love to hear what you find out
since we’re on the topic of cross-compiling C++ to unusual environments: how about this for inspiration?
If I understand right, this thingie is an existing C++ code base recompiled to run as flash in your browser…
Don’t know how much effort it was to port the graphics/audio access to the flash api’s though… And no right-clicks! But still quite impressive
Cool. The flash compiler stuff is pretty neat too (except that I think flash is probably doomed in the long-run). Cross-compiling Juce to javascript/HTML5 is also something I want to investigate.
Googles Native Client (NaCl) might be the solution to both Android and to next generation browser plugins.
It’s c++ and has a crossplatform Multimedia API called Pepper.
Next month the Google App Store will eventually launch, which is also very interesting!
I don’t think I’d want to rely on NaCl - it’s not cross-browser, and they could just ditch it at any time if it’s not a huge success. Better to concentrate on targets like java or HTML5 which have a safer long-term future.