https://kotlinlang.org
Join Slack
Do custom test source sets need an explicit dependency on the main source set? Or is there some magi...
# multiplatform
e
Do custom test source sets need an explicit dependency on the main source set? Or is there some magic convention with the names that sets it up automatically? e.g. in the following example, is 
dependsOn(appleMain)
necessary?
Copy code
with(sourceSets) {
  val appleMain = create("appleMain") {
    dependsOn(getByName("commonMain"))
  }

  create("appleTest") {
    dependsOn(appleMain)
    dependsOn(getByName("commonTest"))
  }
}
j
apple test doesn't need to depend on common test
Copy code
darwinMain.dependsOn(commonMain)
for (darwinMainSourceSet in darwinMainSourceSets) {
  darwinMainSourceSet.dependsOn(darwinMain)
}

darwinTest.dependsOn(commonTest)
for (darwinTestSourceSet in darwinTestSourceSets) {
  darwinTestSourceSet.dependsOn(darwinTest)
}
appleTest depends on commonTest and commonTest already dopends on commonMain
e
I'm not following. I have code in 
commonTest
that I want to use in 
appleTest
so I have that dependency there for that reason. My question is, do I need a dependency on 
appleMain
from 
appleTest
or is one set up automagically?
j
I am not setting it
e
I too have not been setting it, but I'm wondering if I should
e
if you create 
kotlin.targets.apple
then 
kotlin.sourceSets.appleMain
, 
kotlin.sourceSets.appleTest
will be set up, you don't need to create
e
I don't want an 
apple
target; just source sets
o
IIRC, you have to set up that dependency for a custom test target. Only preset test targets come with an implicit dependency on their respective main target.
e
So I do need both
Copy code
dependsOn(appleMain)
dependsOn(commonTest)
o
Yes, that's my understanding.
s
Never out dependsOn edges from *Test to *Main source sets! This visibility will be inferred for you automatically.
So to answer the question: no, the dependsOn(appleMain) should be removed!
e
Is that inference based on convention, e.g. that the source set suffix is 
main
and 
test
?
j
I would like to know more about that target one
@Sebastian Sellmair [JB] is that documented?
currently I am creating each main/test separately but looks like the correct approach is having the properly targets
s
No the inference is not based on names, but based on the concept of associated compilations 👍
j
But is there any difference/utility in creating those targets or they are irrelevant?
o
Given 
main
and 
test
compilations and a modified source set hierarchy like so: • 
commonMain
◦ 
frontendMain
▪︎ 
appleMain
▪︎ 
desktopMain
• 
commonTest
◦ 
appleTest
How would the plugin infer that 
appleTest
should depend on 
appleMain
but not on 
desktopMain
or 
frontendMain
?
j
I guess it is based on what is able to compile as @Sebastian Sellmair [JB] said. Your apple tests are going associated to X number of tests source sets, and those test source sets are matching the same compilation of their respective main sets. So it infer it
e
test source sets are matching the same compilation of their respective main sets
So if 
iosMain
depends on 
appleMain
and 
iosTest
depends on 
appleTest
is the inference that 
appleTest
should depend on 
appleMain
?
j
I think so
e
@Sebastian Sellmair [JB] can you confirm this ☝️
s
Let’s do a meetup in the next days, where I present how this works internally, okay? You can use the following mental model: Think of the main and test hierarchy like two modules/two gradle projects. With this setup we also do the inference for you, right? Its similar in main/test relations: The information about which source sets are visible are coming from the concept of 
associatedCompilations
where test compilations get associated with their main compilations. Based upon this the source set visibility inference is done.
e
Would love to hear more about this in a meetup. Hopefully next week if possible; I'm on a company retreat this week 😅
o
I'd be disappointed if such information were restricted to a hand-picked audience. Can't this be done more openly and cooperatively?
s
Hmmm, I get this request, but I don't know how to process this. I am just an engineer, trying to help 🥴
o
That's excellent and much appreciated. We're all trying to help here and I think that works best if everyone can participate and benefit. In this case, I don't know what options actually exist and what kind of meetup you are referring to – some closed-shop "VIP" thing? If explanations are too complex for this chat, is there a way to have open meetups, for example? Or just have someone from dev rel create a video? Whom to ask about this?
s
No closed or ‘VIP’ kind of things with me. Most of this is as open as this slack channel. Sure, you need to know where to look, but everybody can join. I usually announce the meetup here in this channel and on my twitter. Will announce the next one in a few minutes… 👍
Regarding dev-relations: cc @Pamela Hill
o
Hey, that's I've been asking for! I had asked before for an invitation or some announcement but never got an answer. Your twitter follower count has just increased. All good now. Thank you!
s
but never got an answer.
Oh I am sorry to hear that, where did you ask?
o
Right here and even tagged you directly (which I'm trying to avoid usually): https://kotlinlang.slack.com/archives/C3PQML5NU/p1659714572688459?thread_ts=1659657142.265759&cid=C3PQML5NU
s
Sorry about that! That slipped through, somehow 😢 You’re pretty welcome to join next Monday! The setup is quite simple: Usually, I talk about some random topics (as mentioned in the recent announcement as well) and then we all together just randomly ask questions and talk about things 👍 Should be relaxed
o
Can happen, all good, problem solved. I'll be there! Thank you for offering that one to the community. Really much appreciated and nothing I'd take for granted. ❤️
p
Hi @Oliver.O! I've just started in August so must have missed something in the rigours of starting. How can I help?
o
Hi @Pamela Hill, and welcome! As it finally turned out (see above), you have not really missed anything. Sebastian Sellmair is offering a valuable service to the community, namely an open meetup for multiplatform with implementor-level insights. Due to a misunderstanding, that meetup looked like a private event, which it is not. So everything is fine and there is nothing for dev rel to improve at this stage. Once we discover topics, which might be interesting for dev rel to cover, I'm pretty sure people, including me, will keep you updated. Thanks for being responsive and have a good start! 🚀
p
I'll also try to be at the meetup to say hello 👋
2 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by