https://kotlinlang.org logo
#gradle
Title
# gradle
e

eygraber

03/13/2024, 5:49 PM
Is there any way (or plan) to see the configured hierarchy from
applyDefaultHierarchyTemplate
?
2
But I'm always a bit wary it doesn't tell the full story
e

eygraber

03/14/2024, 12:03 PM
I mean in code, like is there an API for it
m

mbonnin

03/14/2024, 12:04 PM
Yea, I'd love that as well but I haven't seen anything builtin. You could dump the source set hierarchies though
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
c

CLOVIS

03/14/2024, 12:13 PM
Are you sure? I believe
androidTest
does depend on
commonTest
, it's
androidInstrumentedTest
which doesn't.
👍 1
m

mbonnin

03/14/2024, 12:14 PM
Ah yes, probably, sorry I get all confused down there 😅
Is there even an
androidTest
source set?
c

CLOVIS

03/14/2024, 12:15 PM
I think there is one for Android unit tests? It may not be named like this though
m

mbonnin

03/14/2024, 12:16 PM
I think android unit tests always have
UnitTest
in the name, might be wrong though
e

eygraber

03/14/2024, 12:16 PM
It depends on if you're using the V2 layout for android (although that might've been made default)
👍 1
o

Oleg Yukhnevich

03/15/2024, 9:10 AM
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 🙂
a

Adam Semenenko

03/15/2024, 9:32 AM
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
❤️ 1
o

Oleg Yukhnevich

03/15/2024, 10:06 AM
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 🙃
a

Adam Semenenko

03/15/2024, 10:10 AM
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
2
o

Oleg Yukhnevich

03/15/2024, 11:10 AM
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
1
e

eygraber

03/15/2024, 1:59 PM
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.