Thanks to mainline HMPP support in 1.4, my project...

# multiplatform

[serebit]

Thanks to mainline HMPP support in 1.4, my project Logkat can now support every single Linux target currently available with barely any duplicated code! Unfortunately, though, IDEA doesn't seem to have gotten the memo, and still marks all platform declarations in the shared source sets as errors (even though the Kotlin compiler is just fine with them).

[Big Chungus]

Same. IntelliJ is not all that intelligent when it comes to this.

[Sebastian Sellmair [JB]]

Which IDE plugin versions are you using?

[Big Chungus]

Latest.

[serebit]

IDEA 2020.2, Kotlin IDE plugin 1.4.0-RC, and Kotlin Gradle plugin 1.4.0-RC.

[serebit]

If you need an example, clone my project at https://gitlab.com/serebit/logkat and try importing the project into IDEA. It'll sync fine, and compile fine, but all cinterop and platform imports will be marked red in linuxMain, linux64BitMain, and linux32BitMain.

[Sebastian Sellmair [JB]]

I know how frustrating this issue is! I'll promise to push the right people tomorrow. Those parts have been evolving quite some bit and are pretty complex. This and the fact that a lot of knowledge about many subsystems is necessary to get this things right are contributing reasons why this comes up as some kind of "running issue". I am convinced, that this area needs focus now and simplification on our side.

[Sebastian Sellmair [JB]]

Thanks for your sample project!

[serebit]

@Sebastian Sellmair [JB] Is there an issue I can follow on the Kotlin YouTrack for this?

[Sebastian Sellmair [JB]]

I will be discussing your issue and your sample project today. I will post a link to a ticket today 👍

[Sebastian Sellmair [JB]]

So I received feedback for your project 😌
• You might want to add kotlin.native.enableDependencyPropagation=false to your gradle.properties to enable commonizer
• HMPP with commonizer is currently limited to 3 levels (KT-399324). So using commonizer with intermedate source sets like commonMain -> linuxMain -> linux64BitMain -> ... will not work for now (but is actively worked on)
• It seems like platforms like linuxArm32Hfp and linuxMipsel32 lead to "pretty conservative" commonizing with linuxX64 and linuxArm64. (This part requires a little more investigation)

[serebit]

Thanks for the feedback! I'll try enabling the commonizer when I get home. It's a little disappointing that it won't work past 3 levels of source sets, but it's still better than duplicating everything 😛 On the third point, I imagine the bit size has something to do with it. The fread function in posix takes a ULong parameter on 64-bit platforms, but a UInt on 32-bit platforms, which is why I had to create the LinuxXXBitMain source sets in the first place.

[serebit]

Is the commonizer being disabled the cause of IntelliJ not registering intermediate source sets? If that's the case, I'm surprised the compiler doesn't see any issues with it.

[louiscad]

@serebit The compiler just combines all source sets for the platform it's compiling for, resolving any expect declaration with matching actual declarations. In other words, common and intermediate source sets are seen as platform source sets for the compiler (at least for now).

[serebit]

Yeah, the commonizer is having trouble with some posix functions, seemingly. The main thing I'm running into is the disparity between functions returning/parameterizing Int and Long, depending on the bit size of the platform. I guess one potential solution to this would be union types, or relaxing the type restrictions for these cases in common source sets, but I can't imagine it would be an easy thing to program.

[serebit]

Thing is, my code is valid without the commonizer, and it would be reasonable (imo) to expect it to work with the commonizer, even if it has to dance around the type system a little bit.

[serebit]

Not sure if you guys have a plan to address that though.

[serebit]

@Sebastian Sellmair [JB] I enabled dependency propagation, and IntelliJ is fine with the project now, but the compiler is having problems! Now, if I try compiling Logkat with an empty Konan directory (as in, without the dependency tars downloaded), it gets halfway through the build before failing due to unresolved symbols in the 32Bit source set. It works fine with dependency propagation enabled.

[serebit]

You can see the log in the CI build here: https://gitlab.com/serebit/logkat/-/jobs/670687387

[serebit]

Seems like the commonizer needs some work 😛 https://youtrack.jetbrains.com/issue/KT-40822