Skip to content

KotlinLoggingConfiguration is not accessible on nativeMain #494

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

Open
sureshg opened this issue Apr 5, 2025 · 8 comments
Open

KotlinLoggingConfiguration is not accessible on nativeMain #494

sureshg opened this issue Apr 5, 2025 · 8 comments

Comments

@sureshg
Copy link

sureshg commented Apr 5, 2025

I'm developing a Kotlin Native CLI application where most of the code is in the nativeMain source set. This code depends on a shared module, which uses the io.github.oshai.kotlinlogging library in its commonMain source set.

I need to configure the logging specifically for the native target (e.g., add a FileAppender, change log levels). It seems the way to do this might be through KotlinLoggingConfiguration. However, I can't seem to access or configure this from my nativeMain code – KotlinLoggingConfiguration isn't resolving in the IDE within that context.

Image

Does it make sense to move this configuration class to commonMain instead of defining in the directMain intermediate sourceset Or is there a standard way to handle native-specific logger configuration within nativeMain itself?

Copy link

github-actions bot commented Apr 5, 2025

Thank you for reporting an issue. See the wiki for documentation and slack for questions.

@sureshg sureshg changed the title KotlinLoggingConfiguration is not accessible on nativeMain KotlinLoggingConfiguration is not accessible on nativeMain Apr 5, 2025
@oshai
Copy link
Owner

oshai commented Apr 6, 2025

Hi,
directMain is the common module for all platforms that have implementation of logging in the lib itself. In other platforms the configuration is not relevant. Can you depend on directMain instead of commonMain?

@sureshg
Copy link
Author

sureshg commented Apr 6, 2025

Apologies for any confusion. My application doesn't utilize a commonMain source set; it only contains nativeMain and nativeTest. I was referring to your source code.

Can you depend on directMain instead of commonMain?

How could we implement that dependency change within our application project? The challenge we face is that the necessary logging configuration isn't accessible from nativeMain. To configure logging, we currently have to explicitly define platform-specific source sets, which is a cumbersome and verbose process.

@sureshg
Copy link
Author

sureshg commented Apr 14, 2025

@oshai sorry for the ping..anything can be done from the library side to access the LoggingConfig from nativeMain ?

@oshai
Copy link
Owner

oshai commented Apr 15, 2025

I think that the option from lib side is to promote KotlinLoggingConfiguration to commonMain. Other options like splitting to more complex subprojects are less ideal.

From your side you can create a module for each target and there it should be possible to depend on it. For example ios x64 should have that class.

@sureshg
Copy link
Author

sureshg commented Apr 15, 2025

promote KotlinLoggingConfiguration to commonMain

Thanks! yeah, I think that's the best solution. I would like to avoid creating modules for individual targets as most of my code is on nativeMain.

@oshai
Copy link
Owner

oshai commented Apr 16, 2025

I tried doing it, but it's a bit more tricky. Darwin already have a different impl: https://github.com/oshai/kotlin-logging/blob/master/src/darwinMain/kotlin/io/github/oshai/kotlinlogging/KotlinLoggingConfiguration.kt

The lib "native" is actually just linux targets. What are the targets you're supporting?

@sureshg
Copy link
Author

sureshg commented Apr 17, 2025

What are the targets you're supporting?

Mainly all desktop native targets (macosArm64, macosX64, linuxArm64, linuxX64, mingwX64)

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

No branches or pull requests

2 participants