Hi, i would like to ask is there any plan at all (...

# compose-desktop

[felislynx]

Hi, i would like to ask is there any plan at all (and if any, some roadmap for it) to support ARM architecture? My company want's to migrate old JavaFX application that runs on RaspberryPi to something more modern and currently we are divided between Flutter and QT. We would love to use Jetpack Compose since most of us know Kotlin and play with compose for some time 🙂

[altavir]

Does your hardware have a JVM implementation?

[felislynx]

Yes. It is latest Raspberry Pi OS on RPI 3b+. Application is written in kotlin + JavaFX (tornadoFx)

[altavir]

Then compose desktop should work out of the box. It does not rely on things outside JVM.

[altavir]

Thr problems above are about signing the distribution for IOS, not about the programm itself.

[felislynx]

i've got AWT-EventQueue-0 java.lang.Error : Unknown arch arm

[felislynx]

i've tried by opening new project from wizard, added button and run on rpi

[felislynx]

kotlin("jvm) version 1.4.21

[olonho]

one has to compile Skiko (https://github.com/JetBrains/skiko/) for Linux ARM. Note that macOS ARM is already supported.

[felislynx]

@olonho Ok, mixed input, @altavir wrote that it should work o_O

[altavir]

I forgot that that skiko has some native dependenices.

[felislynx]

Ok i understand, my question is: is this planned and if so, when there might be first pre-alpha or something

[felislynx]

I'm not that good with c/c++ to compile this by myself 😉

[felislynx]

and as i said, i'm willing to wait for even alpha stage to migrate app rather than using QT/Flutter or worse: Electron/React Native 😄

[Dominaezzz]

https://github.com/JetBrains/compose-jb/issues/59 can follow this issue

[altavir]

Based on the userpic he is the author of the issue 🙂

[Dominaezzz]

Ooh, I just noticed. 😅😂

[Dominaezzz]

I thought it looked weirdly familiar.

[felislynx]

Yeah, but i though that i'll ask here just to be able to schedule work on migration from javafx. I really dont want to do it more than once :). Compose is best solution if will be available on rpi. I can put things on hold for few months or if there are no plans for upcoming months, probably qt...

[jim]

@felislynx We don't officially talk about future plans nor commit to dates. That said, there have been a bunch of people requesting RaspberryPi support, so I would speculate that it would happen eventually, sooner or later. In the mean time, as @olonho mentioned, compiling skia/skiko is going to be the best way to unblock yourself.

I would also recommend checking out this thread: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1610493565497900 - and I would recommend that you be super nice to to @Aru and become best friends with him, as he may have some tips and be able to help you out.

As always, community contributions are welcomed.

[Aru]

Alright, here's where I'm at.
I tried building Skia in two different ways and I was successful in one of them.
• I built it by disabling building most of the dependencies and making it use the system dependency. For ex, skia_use_system_libjpeg_turbo=true. This went fine. But I was using BitBake from the Yocto build system to achieve this, and so, I cannot raise a PR for this way of building.
• I tried to install a cross-compiler in Ubuntu docker image and use the scripts from skia-build to build it. I'm getting the below error and I cannot get past it. This looks from libjpeg-turbo. I cannot include the native dependency for libjpeg-tyrbo because it was cross compilation.

FAILED: obj/third_party/externals/libjpeg-turbo/simd/arm/common/libjpeg.jidctfst-neon.o 
aarch64-linux-gnu-gcc -MD -MF obj/third_party/externals/libjpeg-turbo/simd/arm/common/libjpeg.jidctfst-neon.o.d -DTURBO_FOR_WINDOWS -DC_ARITH_CODING_SUPPORTED=1 -DD_ARITH_CODING_SUPPORTED=1 -DUSE_CLZ_INTRINSIC -DNDEBUG  -w -Wno-attributes -fstrict-aliasing -fPIC -fvisibility=hidden -O3 -fdata-sections -ffunction-sections -Wno-sign-conversion -Wno-unused-parameter -march=armv8-a -O3 -isystem /src/skia/third_party/libjpeg-turbo -isystem /src/skia/third_party/externals/libjpeg-turbo  -c ../../third_party/externals/libjpeg-turbo/simd/arm/common/jidctfst-neon.c -o obj/third_party/externals/libjpeg-turbo/simd/arm/common/libjpeg.jidctfst-neon.o
../../third_party/externals/libjpeg-turbo/simd/arm/common/jidctfst-neon.c: In function 'jsimd_idct_ifast_neon':
../../third_party/externals/libjpeg-turbo/simd/arm/common/jidctfst-neon.c:87:28: error: incompatible types when initializing type 'int64_t' {aka 'long int'} using type 'int64x1_t'
   87 |   int64_t left_ac_bitmap = vreinterpret_s64_s16(vget_low_s16(bitmap));
      |                            ^~~~~~~~~~~~~~~~~~~~

I was proceeding with compilation of skiko inside the Yocto build system. But Skiko uses Gradle to compile the C++ code and do linking with Skia. Gradle does not support external toolchains other than gcc in Linux. The cross-compiler I wanna use is aarch64-fslc-linux-gcc. I'm trying to extend the AbstractGccCompatibleToolChain in Gradle to use a new toolchain but i've been unsuccessful so far.

[felislynx]

@Aru do you have any progress on arm build?

[Aru]

I tried compiling the C, C++ stuff with the native compiler with CMake separately and modified the gradle build to bind it with Skiko. It all compiled fine but there were some Undefined symbol errors while I run it in the embedded board. I couldn't get it to work properly and our deadline to finalize a UI framework/research was coming to an end. We gave up and decided to go with JavaFX. I'd have loved for compose to work.

[felislynx]

Maybe it is worth to share github link to your work and maybe someone with time and knowledge might push it further. My knowledge from c++ is quite limited so i can't help. I would love to see compose on RPI since JavaFX is... horror to work with 😄