Add Kotlin Native targets

[russellbanks]

This adds Kotlin Native targets to Kaml:

• mingwX64
• linuxX64
• macosX64
• macosArm64

These are the ones that are supported by SnakeYaml KMP at the moment. More can be added once they support more.

This PR does the same as #437.

Alternatively, the code can be moved into commonMain so that we would only have a common module but there are still platform specific functions for the JVM like decodeFromStream, etc, and I'm not sure on how to integrate that while the other code goes in commonMain. However, there is the consideration of the maturity of SnakeYaml KMP with putting the code into commonMain - #437 (comment):

Long-term, I'm totally for it as well, but for now our KMP port is yet immature and using it already for the JVM could introduce some regressions

Because this is the same as the JS code, another option is to create a non-JVM source set rather than nativeMain and jsMain.

I'm not sure why but Batect doesn't seem to like the Native tests.

It might be worth also running the CI on Windows, Linux and macOS rather than just Linux to ensure that the Windows and macOS binaries are building correctly.

@krzema12 @aSemy

[charleskorn]

I'm not sure why but Batect doesn't seem to like the Native tests.

Not sure either - I'll take a look. I'm considering removing Batect from this project altogether, so this might be the thing that pushes me to do it.

It might be worth also running the CI on Windows, Linux and macOS rather than just Linux to ensure that the Windows and macOS binaries are building correctly.

That would be great - could you please add that? (Feel free to wait until I've removed Batect if that's easier.)

[charleskorn]

Because this is the same as the JS code, another option is to create a non-JVM source set rather than nativeMain and jsMain.

That seems like a reasonable thing to do for now - once the port is in a more stable place, we can figure out how to share the code across JVM and non-JVM platforms.

[aSemy]

That seems like a reasonable thing to do for now - once the port is in a more stable place, we can figure out how to share the code across JVM and non-JVM platforms.

hey @charleskorn, I'm curious about the stability side, because it's definitely important so I'd like to have more of an idea. Have there been any issues with Kaml/JS? If you look in the Maven Central stats, has it been used a lot? If it's been used a fair amount and there are no issues, then I'd say it's stable enough!

However, what is more likely is that if Kaml/JVM switched from SnakeYAML-Java to SnakeYaml-KMP then there might be some subtle changes in behaviour - although based on the YAML Test Suite tests I doubt it.

[charleskorn]

Have there been any issues with Kaml/JS?

Not that I'm aware of - no one has reported any issues.

If you look in the Maven Central stats, has it been used a lot?

I don't have access to any statistics on this unfortunately.

[charleskorn]

I've removed Batect from the CI pipeline - please rebase and see if that helps with the native tests.

[charleskorn]

Could you please add a mention of the experimental native targets to the readme?

Also, could you please expand the GitHub Actions workflow to run the tests on Windows and macOS hosts as well?

[russellbanks]

Also, could you please expand the GitHub Actions workflow to run the tests on Windows and macOS hosts as well?

I've done this in a separate pull request - #470

[russellbanks]

The tests seem to fail when writing reports because of gradle/gradle#21547. For now, we could just run jvmTest while the flattening of tests is worked on, as this would also reduce the length of the file names.

[stale]

This issue has been automatically marked as stale because it has not had any activity in the last 60 days. It will automatically be closed if no further activity occurs in the next seven days to enable maintainers to focus on the most important issues.
If this issue is still affecting you, please comment below within the next seven days.
Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had any recent activity.