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

misc: Set up Kotlin/Native build #1174

Merged
merged 53 commits into from
Nov 14, 2024
Merged

misc: Set up Kotlin/Native build #1174

merged 53 commits into from
Nov 14, 2024

Conversation

lauzadis
Copy link
Contributor

@lauzadis lauzadis commented Nov 6, 2024

Issue #

Description of changes

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@lauzadis lauzadis marked this pull request as ready for review November 13, 2024 15:29
@lauzadis lauzadis requested a review from a team as a code owner November 13, 2024 15:29
import aws.smithy.kotlin.runtime.io.SdkBuffer

/**
* write as much of [outgoing] to [dest] as possible
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: Capitalization

@@ -5,5 +5,5 @@
package aws.smithy.kotlin.runtime.http.interceptors

internal actual fun decompressGzipBytes(bytes: ByteArray): ByteArray {
TODO("Not yet implemented")
TODO("Not yet implemented. Can we write a pure Kotlin implementation?")
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: Leftover comment

Copy link
Contributor

Choose a reason for hiding this comment

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

About the comment itself, I was hoping Okio had already done it but it looks like not yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is not leftover. It's something we should try to do while implementing Native GZIP / before launching Kotlin/Native support

Comment on lines 129 to 132
run: |
./gradlew apiCheck
./gradlew -P"aws.sdk.kotlin.crt.disableCrossCompile"=true build
./gradlew -P"aws.sdk.kotlin.crt.disableCrossCompile"=true allTests
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: Double quotes for the property names seem unnecessary here.

./gradlew -Paws.sdk.kotlin.crt.disableCrossCompile=true build
./gradlew -Paws.sdk.kotlin.crt.disableCrossCompile=true allTests

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I forgot exactly why, but it is necessary on Windows, I'll remove them and see what fails (or if the issue has been fixed since then)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

* What went wrong:
Task '.sdk.kotlin.crt.disableCrossCompile=true' not found in root project 'smithy-kotlin' and its subprojects.

Comment on lines 66 to 71
run: |
# FIXME K2. Re-enable warnings as errors after this warning is removed: https://youtrack.jetbrains.com/issue/KT-68532
# echo "kotlinWarningsAsErrors=true" >> $GITHUB_WORKSPACE/local.properties
./gradlew apiCheck
./gradlew -Paws.sdk.kotlin.crt.disableCrossCompile=true build
./gradlew -Paws.sdk.kotlin.crt.disableCrossCompile=true allTests
Copy link
Contributor

Choose a reason for hiding this comment

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

Question: Why run allTests again after build? Doesn't build already include allTests as a prerequisite? (same question in other blocks)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes I think you're right, this was a leftover copy-paste where only allTests was running

Comment on lines 4 to 6

aws-kotlin-repo-tools-version = "0.4.13"
aws-kotlin-repo-tools-version = "0.4.15-kn"

Copy link
Contributor

Choose a reason for hiding this comment

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

Question: Does this mean we have to maintain parallel releases of the repo tools until we're ready to fully GA Kotlin/Native support? What's unsafe/unready about the K/N support in repo tools now that prevents it from being merged to main and used for all smithy-kotlin branches including main?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The main difference so far is all the targets which get enabled: awslabs/aws-kotlin-repo-tools@main...kn-main

I think we might be able to move this to main and drop the parallel versioning strategy.

This parallel release strategy is something that's been planned from the beginning. I can't say for sure but there may be more changes forthcoming which will require us to have this split.

Comment on lines +28 to 29
// FIXME This test implements [TestWithLocalServer] which is JVM-only.
class AsyncStressTest : TestWithLocalServer() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Question: Are we tracking these K/N-specific FIXMEs/TODOs somehow? I'm worried that some may slip through the cracks as we fill out Native support.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not currently. I was imagining we'd spot them during the kn-main -> main merge

Comment on lines 7 to 9
internal actual fun decompressGzipBytes(bytes: ByteArray): ByteArray {
TODO("Not yet implemented")
TODO("Not yet implemented. Can we write a pure Kotlin implementation?")
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Comment: We can but we probably shouldn't for performance and correctness reasons. We should look for existing platform implementations where possible. For Native that probably means binding to something like zlib or CRT.

@@ -26,6 +26,7 @@ import kotlin.time.toKotlinDuration
import java.time.Duration as jtDuration
import java.time.Instant as jtInstant

// FIXME Consider making this multiplatform (`common`) using kotlinx.datetime
Copy link
Contributor

Choose a reason for hiding this comment

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

Comment: Early in the SDK design, we rejected kotlinx-datetime as a backing impl because of concerns about support and long-term stability. These concerns might be addressed once kotlinx-datetime is promoted to Beta or once Instant and Clock are moved to stdlib.

Comment on lines 29 to 37
// Set up aws-crt-kotlin as a composite build
val localAwsCrtKotlin = file("../aws-crt-kotlin")
if (localAwsCrtKotlin.exists()) {
println("Including aws-crt-kotlin as a composite build")
includeBuild(localAwsCrtKotlin)
} else {
println("Could not find aws-crt-kotlin in a sibling directory, not including it")
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggestion: This seems brittle. I'd rather see a more flexible solution like we have for aws-sdk-kotlin, ideally extracted into the repo tools if that's possible.

Copy link
Contributor Author

@lauzadis lauzadis Nov 13, 2024

Choose a reason for hiding this comment

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

What's brittle about it besides not supporting a local.properties file? Does anyone even use that configuration option? I didn't see any use of it in our CI / other tooling

Comment on lines 29 to 37
// Set up aws-crt-kotlin as a composite build
val localAwsCrtKotlin = file("../aws-crt-kotlin")
if (localAwsCrtKotlin.exists()) {
println("Including aws-crt-kotlin as a composite build")
includeBuild(localAwsCrtKotlin)
} else {
println("Could not find aws-crt-kotlin in a sibling directory, not including it")
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Question: This sets up a composite build with aws-crt-kotlin for smithy-kotlin but what if I'm building aws-sdk-kotlin and I'm already setting compositeProjects=../smithy-kotlin,../aws-crt-kotlin? Does the CRT project get built twice? Does it fail?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't configure compositeProjects at all and my aws-sdk-kotlin build gets resolved correctly with all three projects included

Comment on lines 56 to 59
// FIXME This is the only thing keeping this directory in `jvm`, could be `jvmAndNative`
get("/gzipped") {
val uncompressed = ByteArray(1024) { it.toByte() }
val compressed = ByteArrayOutputStream().use { baStream ->
Copy link
Contributor

Choose a reason for hiding this comment

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

Question: Don't we already know we need KMP GZip support and already have expect/actual declarations for it? Can we use those here and then move this to the jvmAndNative source set? Or do other blockers remain?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe we can use our expect/actual declarations, I'll take a look. Right now this is using java.util.zip.GZIPOutputStream which is definitely JVM-only

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Moved to jvmAndNative by using our existing GzipSdkSource class

@lauzadis lauzadis merged commit 9d9faf3 into kn-main Nov 14, 2024
7 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants