Hi everyone, is there a way to define release and debug build variants?

# compose-desktop

[Pavle Joksovic]

Hi everyone, is there a way to define release and debug build variants?

[Big Chungus]

No, it's not android, so there's no need for release and debug artefacts

[jw]

What about Android makes the need for debug and release variants unique? I build debug and release variants for Chrome extensions, web apps, native apps, and JVM apps just the same.

[Big Chungus]

Dunno, but never heard jvm app having a debug variant. It's just a jar in the end

[Big Chungus]

My guess would be that android and chrome extensions have size concerns that result in separate release variant and native just writes separate debug symbols to facilitate debugging.

[Big Chungus]

But if you still want a "release" variant, I think you could still shrink it with proguard before giving it away to jpackage

[jw]

You need to look past pure binary shape and think more of features. Debug builds can have developer functionality like synthesizing state, replacing external dependencies, and altering rendering.

But binary properties like shrinking and obfuscation are also important for some cases, too, like you said.

[spierce7]

@Pavle Joksovic I’ve worked around this in a bit of a hacky way. I look for a gradle property in the gradle build. If I find it then I add the production source set directory, and if I don’t find it, I add the internal source set directory.

This gives me way to add some code in internal builds that isn’t there in production builds. It gives a lot of flexibility to do what you want.

I also remember seeing some Kotlin plugins mentioned here that generate something similar to a BuildConfig file.

[tad]

buildSrc + KotlinPoet = gradle writes your code for you

[tad]

Just draw the rest of the owl