Support intermediate SourceSet(a.k.a. HMPP)

[yshrsmz]

resolve #38
fix #59

[TobiasPr]

Why did you decide that the hierarchical higher source set always has precedence? I think this is counter intuitive. I think about as inheritance in which lower hierarchical source set inherits the props from the higher source set, but it should still be able to set a more specific value
right now we have a sourceset hierarchy like this:
commonMain/
├─ jvmMain/
│ ├─ androidMain/
├─ iosMain/

for androidMain the buildkonfig is not generated - only for the jvmMain

[yshrsmz]

That's a good question.

That's because you can only have one actual declaration in sourceset hierarchy.

If you want targetConfig in androidMain, then you can't have it in jvmMain. 2 actual declarations in a hierarchy simply throws a compile error.

Which we should prefer is something I couldn't find a good answer.

What is your desired behavior?
I think I can change it, but then what jvmMain can see is fields defined in defaultConfigs.

[TobiasPr]

Thanks for replying so quickly :)

In our case we build our application for jvmMain, androidMain (which is currently 100% identical source sets wise but we would like to set some differnent value on buildkonfig) and iosMain. Here is a part of our build.gradle.kts:

sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("common.dependency:1.2.3")
            }
        }

        val jvmMain by getting {
            dependsOn(commonMain)
            dependencies {
                api("some.dependency:1.2.3")
                ...
            }
        }

        val androidMain by getting {
            dependsOn(jvmMain)
        }
...
}

val versionName = "1.2.3"
buildkonfig {
    packageName = "com.mypackage"

    // default config is required
    defaultConfigs {
        buildConfigField(STRING, "semanticVersionName", versionName)
        buildConfigField(STRING, "osName", "common")
    }

    targetConfigs {

        create("jvm") {
            buildConfigField(STRING, "osName", "jvm")
        }

        create("android") {
            buildConfigField(STRING, "osName", "android")
        }

        create("ios") {
            buildConfigField(STRING, "osName", "ios")
        }
    }
}

if we build for android the generated buildkonfig is the same as for jvm and it would be cool to have them differently. I am not that experienced in KMM so I am not sure if it is just a use case of ours and whether we actually need to make the distinction between jvm and android. I was just thinking whether this inheritance like behavior could also solve the limitations mentioned in the ticket #38 for Desktop systems, which seem a similar use case - but maybe I did not understand the technical limitations correctly

[yshrsmz]

Ah got it. your jvmMain is an intermediate SourceSet, but also a "terminal" SourceSet.
I didn't consider that usecase.

Can we move the discussion to the new issue( #64 ), so that others can join?