Is there any way (or plan) to see the configured h...

# gradle

[eygraber]

Is there any way (or plan) to see the configured hierarchy from applyDefaultHierarchyTemplate?

[mbonnin]

There is a png in the docs https://kotlinlang.org/docs/multiplatform-hierarchy.html#see-the-full-hierarchy-template

[mbonnin]

But I'm always a bit wary it doesn't tell the full story

[eygraber]

I mean in code, like is there an API for it

[mbonnin]

Yea, I'd love that as well but I haven't seen anything builtin. You could dump the source set hierarchies though

[mbonnin]

https://twitter.com/martinbonnin/status/1714292699283816897

[mbonnin]

What bugs me a bit is that the hierarchy template doesn't match 1:1 the sourceSet graph. Like androidTest does not depend on commonTest . I get the reason why (not running unit tests twice) but the template abstraction is a bit misleading

[CLOVIS]

Are you sure? I believe androidTest does depend on commonTest , it's androidInstrumentedTest which doesn't.

[mbonnin]

Ah yes, probably, sorry I get all confused down there 😅

[mbonnin]

Is there even an androidTest source set?

[CLOVIS]

I think there is one for Android unit tests? It may not be named like this though

[mbonnin]

I think android unit tests always have UnitTest in the name, might be wrong though

[eygraber]

It depends on if you're using the V2 layout for android (although that might've been made default)

[Oleg Yukhnevich]

You can also make androidInstrumentedTest depend on commonTest , without dependsOn if that's what you need
Example: https://github.com/whyoleg/cryptography-kotlin/blob/138bb7076645105a48885e12c61199[…]-logic/src/main/kotlin/ckbuild.multiplatform-android.gradle.kts
Still, it's experimental API, and so could change/disappear 🙂

[Adam Semenenko]

Good idea, being able to see the actualised hierarchy could be really useful. It's possible to make it in KGP, but I think this would be a good feature request for Dokka (since it's more about documentation).

Dokka also has an issue related to how source sets are displayed https://github.com/Kotlin/dokka/issues/2779

[Oleg Yukhnevich]

Good idea, being able to see the actualised hierarchy could be really useful.

BTW, what specific information do you want to see here, that will be helpful? Not that I don't the reason for this, but I'm interested to hearing your ideas/use-cases?
P.S. I'm also ready to hear opinions of others (not only Adam) on this 🙃

[Adam Semenenko]

When I consume a KMP library, it'd be handy to see what the structure is. For example, Okio recently moved FileSystem to a source set that I think is shared by JVM & Native, but not JS and Wasm. So it'd be handy to see FileSystem is in FooSharedSourceSet, and that's not a parent of JsSourceSet

[Oleg Yukhnevich]

So, overall, you want to know for which targets declaration is available, right? You don't really need to know which specific sourceSet it is, right?
F.e if you would see, that FileSystem is marked with some tags like jvm + native it will be fine?
Or may be you do want to know it for all declarations, and f.e just enable a filter for all declarations (in the same things like jvm + native)?
The reason I asking is that there are different ways to show this information in API reference, and may be not all of them are compatible with each other and could add a lot of noise there

Note: if you think, that this theme is off-topic, we could more to #dokka 🙂
If not, I would like to hear more about other use cases for such functionality

[eygraber]

My use case would be to support this function which creates tasks for each group. What I have works, but I'm thinking it'll probably be cleaner if I could read the hierarchy.