Fix classpath when source set has no metadata compilations #4296
Conversation
|
JIC: my attempt to fix |
12c2bb1 to
4dd9e43
Compare
4cddab4 to
685f09b
Compare
d2b6dd7 to
747573f
Compare
685f09b to
62d4bff
Compare
d249aa3 to
ab74561
Compare
whyoleg
left a comment
There was a problem hiding this comment.
Please take a look on the comment in KotlinAdapter
| } | ||
|
|
||
| @OptIn(org.jetbrains.kotlin.gradle.ExperimentalWasmDsl::class) | ||
| wasmJs { |
There was a problem hiding this comment.
Could you please add wasmWasi target and declarations in wasmMain, so that we can be sure, that we test the original issue from kotlinx-io?
webMain and wasmMain might behave differently I believe.
Note: that wasmMain is not created automatically.
There was a problem hiding this comment.
I'll add a functional test that adds a custom shared WasmJS/WasmWASI source set. I think it's best to avoid adding custom source sets into the example projects, so as to keep them simpler.
There should be no differences between a shared source set that's provided by KGP and one that's defined by users.
dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt
Outdated
Show resolved
Hide resolved
|
|
||
| // This KotlinSourceSet has no primary compilations, therefore it must be an intermediate source set | ||
| // e.g. mingwMain or webMain. | ||
| // If there are no metadata compilations then we must include the classpaths of the actual targets, |
There was a problem hiding this comment.
So, in case of webMain or wasmMain, which compilations will be there?
For some reason, I think that at least in the case of wasmMain we will have both wasmJs and wasmWasi compilations, and so we will add classpath from both of them, potentially having conflicting klibs.
For webMain, on the other hand, I believe that a shared compilation already exists, but I might be wrong.
All of these points indicate that this PR will address #3386, and not #4116.
I do think that we need a functional test here, which will check the classpaths of source sets.
452538e to
55e4830
Compare
|
I've discussed more with @abdulowork and we think we've found a better workaround. We can use IdeMultiplatformImport to get the same data that IJ uses. I'll have another attempt... |
|
Unfortunately while Investigations are ongoing... |
### Fix 'bamboo' source sets. If an intermediate source set only has one actual KMP target this is informally known as a 'bamboo' source set (because, unlike a 'tree', a bamboo does not have branches). For example, `windowsMain` and `mingwMain` only have one target: `mingwX64Main`. In `KotlinAdapter` an intermediate source set does not have any `primaryCompilations`. If an intermediate source set only has a single 'associated compilation' then it will be considered as a 'bamboo' source set. The single 'associated compilation' is the actual target compilation. and DGP will use the classpath of actual target. ### Workaround no metadata compilations for shared Wasm source sets (workaround for KT-80551) KGP registers metadata compilations for source sets that have multiple native compilations, but _not_ for multiple wasm source sets. This PR works around this by using an `internal` KGP function to register the metadata compilation for shared wasm source sets. Workaround for: - https://youtrack.jetbrains.com/issue/KT-80551 - #4116 ### Stop adding source directories to classpath For some reason DGPv2 adds source directories to the classpath. I didn't dig into the reason, but it seems to have no purpose. So I just removed this: https://github.com/Kotlin/dokka/blob/v2.1.0/dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt#L204-L206
…pilable before!) - Add 'webMain' source set.
54135fe to
c49cefc
Compare
This PR contains a fix for two situations where a source set's classpath does not contain the required KMP klibs for Dokka to resolve symbols in the source set's code.
Fix 'bamboo' source sets.
If an intermediate source set only has one actual KMP target this is informally known as a 'bamboo' source set (because, unlike a 'tree', a bamboo does not have branches).
For example,
windowsMainandmingwMainonly have one target:mingwX64Main.In
KotlinAdapteran intermediate source set does not have anyprimaryCompilations.If an intermediate source set only has a single 'associated compilation' then it will be considered as a 'bamboo' source set. The single 'associated compilation' is the actual target compilation. and DGP will use the classpath of actual target.
Workaround no metadata compilations for shared Wasm source sets (workaround for KT-80551)
KGP registers metadata compilations for source sets that have multiple native compilations, but not for multiple wasm source sets.
This PR works around this by using an
internalKGP function to register the metadata compilation for shared wasm source sets.Workaround for:
Stop adding source directories to classpath
For some reason DGPv2 adds source directories to the classpath. I didn't dig into the reason, but it seems to have no purpose. So I just removed this:
https://github.com/Kotlin/dokka/blob/v2.1.0/dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt#L204-L206
Fix and update kotlin-multiplatform-example
kotlin-multiplatform-exampleto be compilable (it wasn't compilable before!)