Hi, is HMPP ready to be tried in 1.3.70 EAP 3? I'd...

# compiler

[louiscad]

Hi, is HMPP ready to be tried in 1.3.70 EAP 3? I'd like to try it for the #splitties libraries

[dmitriy.novozhilov]

cc @dsavvinov

[dsavvinov]

Almost 😉 We’re preparing a blog-post with all details and an example for 1.3.70, so “stay tuned”

[louiscad]

Will it work for iosArm32 as well? I noticed that the new ios preset from the Gradle plugin skips it, making it incompatible with old iPads, many iPod touch generations and iPhone 5C or older. I'd like to be able to benefit from HMPP while still allowing my library to run on these devices. Maybe a support32bits parameter that would default to false, or true could be added? I'm bringing that to the table as I know the paint is not dry yet, and I'm curious if not supporting 32 bits by default is deliberate, and if so, why.

[dsavvinov]

The issue is in your dependencies.

One of the scenarios enabled by new iteration of MPP is an ability to write true “native-shared”-code, like iosShared, which shares code across all ios-related targets.

Major challenge here is to provide correct dependencies against which this code will be analyzed in IDE/compiled — as we all remember, if you have source-code shared across N native targets, you’ll end-up with N instances of all libraries (posix, Foundation, etc.), all of which are slightly different. To prevent unexpected compilation/linkage errors, we have to understand which exactly parts of specific library are common (and thus safe to use in native-shared source-set) among all platform-specific implementations of that library.

We solve it by automated approach, where we, roughly speaking, compare platform-specific implementation of a library and mark everything which is the same (in a broad sense of same) as safe-to-use-in-common.

Unfortunately, straightforward approach yields almost no common API between 32 and 64-bit platforms because of platform-dependent integers, and finding common type between Int and Long is a tricky task. ios-preset is meant to provide “plug-n-play” UX for ios-development, so for the first iteration we’ve decided to drop 32-bit platforms from it (because we won’t be able to provide plausible UX for them anyways). Still, that’s definitely on our table.

[louiscad]

Is the story different when it comes to watchOS APIs?