Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix DGP/KMP integration, so Dokka can 'see' code from shared source sets in target source sets #3814

Merged
merged 96 commits into from
Nov 26, 2024

Conversation

adam-enko
Copy link
Member

@adam-enko adam-enko commented Sep 19, 2024

There are 3 main fixes in this PR:

  1. Update determining the Kotlin target for each source set. (See KotlinAdapter#determineKotlinPlatform). Filter out metadata targets (they're not relevant for target determination), and only fall back to KotlinPlatform.Common if necessary.
  2. Correctly resolve Konan dependencies: Use compilation.konanTarget.name instead of compilation.target.name.
  3. Fix fetching the classpath: For Android projects, fetch both jar and android-classes-jar dependencies. For KGP projects, use compileDependencyFiles.

The remaining changes are to support these fixes:

  • Add functional test to verify that Dokka can correctly generate docs when 'leaf' source sets (e.g. linuxX64) reference 'branch' source sets (e.g. commonMain, nativeMain).
  • Update DGPv2 AGP integration test data.
  • Create a factory for creating DokkaSourceSetSpecs, which means DGP can consistently use convention() to set default values.
  • Add/update KDoc.

Should fix KT-70857

@adam-enko adam-enko added the runner: Gradle plugin An issue/PR related to Dokka's Gradle plugin label Sep 19, 2024
@adam-enko adam-enko self-assigned this Sep 19, 2024
…ndents

# Conflicts:
#	dokka-runners/dokka-gradle-plugin/src/main/kotlin/internal/uriUtils.kt
- Filter out legacy KMP metadata compilations (they were retained to support Dokka v1).
- Fetch both `jar` and `android-classes-jar` from AGP (probably not necessary, but why not?)
- Only use `compilation.compileDependencyFiles` in non-AGP projects.
- Add more docs
- implement new JUnit extension to help set up and re-run DGP integration tests with different versions
…ses, tidy Android projects, fix suppress/analysisPlatform defaults.
adam-enko added a commit that referenced this pull request Oct 31, 2024
`fileTree.kt` contains a utility for logging pretty file trees, which is useful in providing human-readable context for test failures.

This PR updates the utility to only use NIO Path, rather than the older `java.io.File`.

This change was split off from #3814 to make the PR smaller
adam-enko added a commit that referenced this pull request Oct 31, 2024
`fileTree.kt` contains a utility for logging pretty file trees, which is useful in providing human-readable context for test failures.

This PR updates the utility to only use NIO Path, rather than the older `java.io.File`.

This change was split off from #3814 to make the PR smaller
…ndents

# Conflicts:
#	.gitattributes
#	build.gradle.kts
#	dokka-integration-tests/gradle/build.gradle.kts
#	dokka-runners/dokka-gradle-plugin/src/main/kotlin/tasks/DokkaGenerateTask.kt
#	dokka-runners/dokka-gradle-plugin/src/testFixtures/kotlin/GradleTestKitUtils.kt
#	dokka-runners/dokka-gradle-plugin/src/testFixtures/kotlin/fileTree.kt
- Filter out metadata compilations when determining the source set target.
- Remove KotlinPlatform warning - it's always triggered for commonMain.
- Fetch _all_ dependent source sets, including transitives.
@adam-enko adam-enko changed the title Fix common source sets not propogated Fix DGP/KMP integration, so Dokka can 'see' code from shared source sets in target source sets Nov 21, 2024
@adam-enko adam-enko requested a review from whyoleg November 21, 2024 18:54
@adam-enko adam-enko added this to the Dokka 2.0.0 milestone Nov 21, 2024
@adam-enko adam-enko marked this pull request as ready for review November 21, 2024 18:55
Copy link
Collaborator

@whyoleg whyoleg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!
Changes to defaults are looks logical for me, only the test placement worries me :)

import kotlin.io.path.walk

@Ignored("KMP: References is not linked if they are in shared code and there is an intermediate level between them https://github.com/Kotlin/dokka/issues/3382")
class KmpCommonSourceSharedWithDependentsTest : FunSpec({
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this test should be placed into dokka-integration-tests so that we will be able to check it with different Kotlin versions.
In my understanding, functional tests in DGPv2 are more about plugin behavior while this test is more about overall Dokka behavior and so should be in IT

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably except here a test which checks that we set correct defaults for DokkaSourceSetSpec platform, dependsOn and etc

Copy link
Member Author

@adam-enko adam-enko Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this test should be placed into dokka-integration-tests

Good idea, done.

Could you check the expected data in dokka-integration-tests/gradle/projects/it-kotlin-multiplatform/expectedData/html? There are errors, but I'm not sure if any are DGP's responsibility, or are caused by #3382

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, it doesn't look like TeamCity likes the KMP IT. Some of the tests are failing.

https://ge.jetbrains.com/s/ndo3qeb66whvy/tests/overview?outcome=FAILED

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've checked expectedData/html and it looks reasonable and the error is most likely caused by #3382.
let's ignore test and re-check it in scope of #3930 (DGPv2 + K2)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The difference in OS (linux vs macOS) and so probably the difference is in dependencies passed inside KGP. E.g iOS targets are not compilable on linux and so probably the classpath (or some other configuration) is somehow different, which causes this behavior.

In this case, I think that for this test probably having just linux targets should be enough to reproduce the issue, correct?
We could also try to add mingw target (or androidNative targets), or add additional intermediate sourceSets somewhere, so that all targets will be cross-compiled on all OSs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could understand it if locally, on my Mac, I would get no errors and on Linux the macOS targets would cause Unresolved type errors, but I don't see why it's the other way around. I'd like to understand the problem more before trying to work around it, but I'm not sure how.

I'll check with my team.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that it's better to compare configurations on CI (linux) vs on macOS and then think about what could go wrong.

Also, I would propose in any case add second targets for iOS and linux, as Dokka doesn't work well with single target source sets - may be it could be also cause difference in produced configuration in this case.
E.g, we have an issue with K2: #3386, may be something similar also exists in K1.
Again, the first step will be to obtain configuration used to run Dokka and compare them

Copy link
Member Author

@adam-enko adam-enko Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From looking at the Dokka configuration, it looks correct (both locally and on TeamCity), so I'm going to chalk the failures up to issues with K1 analysis and disable the HTML output validation tests. They're not critical for this PR anyway.

@adam-enko adam-enko force-pushed the adam/feat/KT-70336/pass-common-src-to-dependents branch from 31d28b3 to b58d42f Compare November 26, 2024 12:15
@adam-enko adam-enko merged commit b7102d4 into master Nov 26, 2024
14 checks passed
@adam-enko adam-enko deleted the adam/feat/KT-70336/pass-common-src-to-dependents branch November 26, 2024 15:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
runner: Gradle plugin An issue/PR related to Dokka's Gradle plugin
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants