Hello :wave: I have an internal library that we us...

# library-development

[gsala]

Hello 👋
I have an internal library that we use for debugging. I was thinking of providing a “-no-op” version of the library with the same implementation as the main lib, but empty implementations so it can be used in release builds without any effect.
What’s the best way to do this? I could do it manually as the public API is very small, but is there a built-in solution that generates the no-op version from the public API by using e.g. KotlinPoet and Metalava?

[CLOVIS]

You could use https://github.com/Kotlin/binary-compatibility-validator to dump the API, and then use KotlinPoet to generate stub code from the dump?

[franztesca]

You can also make your API part of a DSL that is compiled only in debug builds thanks to inlining.

debug {
  val myVariable = expensiveComputation()
  log(myVariable) // log is part of the DSL of your library
}

// In debug builds
inline fun debug(block: Debug.() -> Unit): Unit = DebugImpl.run(block)

// In production builds
inline fun debug(block: Debug.() -> Unit): Unit = Unit

In this way you could isolate entire blocks of code that compiled only in debug builds.
The generation of the debug function can be done with KSP with no need for additional no-op library.

[gsala]

Ah thanks @CLOVIS. I didn’t know about this one, very valuable. My plan so far is creating the stubs manually, but having a CI check that verifies the API from the manual stub and the real lib are aligned, before I can merge and release a new version of the lib.
I was planning on doing this alignment/comparison by comparing Metalava outputs, but I guess I could also use this lib to do that. I’m still investigating, as Metalava also mentions something about stub generation.

[CLOVIS]

Well, if you're going to go with the inline route, use a const val DEBUG_ENABLED = false inside your inline function, no need for code generation at all

[gsala]

@franztesca The inlining would only work for debug versions of the library right? Maybe I’m confusing something but I think that’s different from what I want, which is a released library that can be used in debug versions of an Android app, and a released stub that can be used in the release version of the Android app

[ephemient]

for a JVM-only library, I think it would be easily done by transforming the bytecode, e.g.

build.gradle.kts.kt