Fix classpath when source set has no metadata compilations#4296
Fix classpath when source set has no metadata compilations#4296
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
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
dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt
Outdated
Show resolved
Hide resolved
dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt
Outdated
Show resolved
Hide resolved
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
whyoleg
left a comment
There was a problem hiding this comment.
Overall, the changes appear to be fine, and the workaround for the problem seems quite isolated.
The only thing that bothers me is that it looks like the fix on the KGP side - just compiling wasmJs + wasmWasi as if it were wasmWasi + native, e.g., via metadata compilation - might have been easier :)
dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt
Outdated
Show resolved
Hide resolved
dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt
Outdated
Show resolved
Hide resolved
dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt
Show resolved
Hide resolved
dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt
Show resolved
Hide resolved
...unners/dokka-gradle-plugin/src/main/kotlin/adapters/TransformedMetadataDependencyProvider.kt
Outdated
Show resolved
Hide resolved
...unners/dokka-gradle-plugin/src/main/kotlin/adapters/TransformedMetadataDependencyProvider.kt
Outdated
Show resolved
Hide resolved
…()` in separate file to avoid file-level `internal` suppression, and add failure handling inside `map {}`.
|
Failing tests are due to the year change, and are fixed by #4406 |
whyoleg
left a comment
There was a problem hiding this comment.
Nice! Thanks for the hard work on finding how to fix this on Dokka side!
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.
Fixes #3386
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!)