Kotlin-native: Include a common kotlin gradle project

[MarkusAmshove]

Hello,

since Kotlin 1.2 was released with the experimental feature of multiplatform projects for Kotlin I've tried to also include a native project into my build chain.

The project is structured as this:

: root
-> :common
-> :jvm
-> :js

where root is just the root gradle file and both jvm and js depend on :common (via the expectedBy).

The following is my skeleton of the build.gradle file of the native project:

buildscript {
   repositories {
       mavenCentral()
       maven {
           url  "https://dl.bintray.com/jetbrains/kotlin-native-dependencies"
       }
   }

   dependencies {
       classpath "org.jetbrains.kotlin:kotlin-native-gradle-plugin:+"
   }
}

apply plugin: 'konan'


konanArtifacts {
    program('native')
}

What I've tried so far is:

konanArtifacts {
    program('native') {
        libraries {
            expectedBy project(':common')
        }
}

artifact '../common/build/lib/common.jar'

artifact project(':common', 'common.jar')
artifact project(':common', 'common')
allLibrariesFrom project(':common')

Is this something which isn't just supported yet (native project importing a kotlin-common lib) or is there another workaround which I didn't find yet?

[r4zzz4k]

As far as I know, Kotlin/Native doesn't support multiplatform aspect of Kotlin 1.2 yet, but you still can share the code itself, as JetBrains team done within KotlinConf app or Spinner game.

[goncalossilva]

The KotlinConf app doesn't really reuse any of the code in the iOS module AFAICT. It's all re-written, even the data layer. The Spinner game does though, by sourcing the code directly.

This a bit nasty though, specially if your common module has the expect / actual workflow, which is likely for any meaningful project. I have no idea how sourcing the code directly deals with this though, if at all.

[r4zzz4k]

Looks like it might become available sooner rather than later: #1102.

[MarkusAmshove]

This looks promising!

I've also got it to work with the srcFiles which you guided me to like in the KotlinConf app.

This does work, gradle is able to build the native binary (and therefore also Travis) with all the stuff from the common module, CLion doesn't recognize the sources though.
Are there any plans on how this will work in the future? Will the kotlin native gradle plugin generate the correct CMake file?

If you'd like to have a look how I structured it at the moment, you can find it here (the kluentv2 branch).

I'm writing notes about the transition to multiplatform here: MarkusAmshove/Kluent#75

Edit: added correct Travis link

[r4zzz4k]

Thanks for the link, this looks interesting. I was trying to work with CMake project, but Kotlin support for it looks very preliminary, so I'm going to take a look at current Gradle K/N plugin state (I've looked into extending CMake before and from what I saw the only way to add proper language support is to patch it from inside, not to configure from outside. I'm hoping it would be a thing at some point in the future).

Regarding CLion -- I don't really know if there are plans on supporting Gradle, as you may know there are many requests on different C/C++ build systems and none of them managed to get support yet. Let's wait for a response from the team.

[sureshg]

@r4zzz4k this is the response I got from the Kotlin team - https://www.reddit.com/r/Kotlin/comments/7hoytl/kotlin_team_ama_ask_us_anything/dqthwc4/?context=3

[r4zzz4k]

@sureshg Thanks for the information, great insight!

[MarkusAmshove]

Thanks for the update!

[MarkusAmshove]

I've made some progress in my experimental branch.

I've added the common project as a konanc_library in CMakeFiles.txt, which makes it possible for me to run the tests of the common module within CLion:

And also running the build with gradle:

At the moment the gradle build doesn't use expectedBy, but rather defines an aritfact which in turn is used by the test program:

konanArtifacts {
    // Should be used with expectedBy somewhere
    library('common') {
        srcFiles fileTree('../common/src/main')
    }
    program('native') {
        libraries {
            klib 'common'
        }
        srcFiles fileTree('src/main/kotlin')
    }
}

Gradle isn't building the tests, so it isn't able to execute them.
If I specify the test folder of the common project as program I don't get an executable, because they don't have an entry point (CLion seems to build one itself for the kexe to execute the tests).

I've seen that the Kotlin spinner app also has tests, but I'm not sure how/if they execute them with gradle.

Is my assumption correct that gradle and CMake don't know each other? So that CMake is only used because CLion doesn't understand gradle? If so, will gradle be the prefered buildsystem in the future?

CLion also still doesn't know about the sources from the common project:

But CMake and gradle have no problem compiling and running it :-)

[olonho]

Shall be available at https://github.com/JetBrains/KotlinMultiplatformPlayground