2026-03-23 01:41:39 +02:00
|
|
|
#Kotlin
|
|
|
|
|
kotlin.code.style=official
|
2026-04-27 19:43:23 +02:00
|
|
|
kotlin.daemon.jvmargs=-Xmx12g
|
2026-03-23 01:41:39 +02:00
|
|
|
|
|
|
|
|
#Gradle
|
2026-04-27 19:43:23 +02:00
|
|
|
org.gradle.jvmargs=-Xmx8g -Dfile.encoding=UTF-8
|
build: bump lightning-kmp-app to bbba08b, building lightning-kmp from source
lightning-kmp-app moves 6745d88 -> bbba08b, four commits:
57353cf Minor updates
9f3cd72 Build lightning-kmp from the experimental submodule via a composite build
f22c30a Follow the submodule chain onto Gradle 9.7.1
bbba08b Declare the ios targets only on a mac, so the IDE can import the project
9f3cd72 is the substantive one. lightning-kmp no longer comes from maven central: the
submodule now carries its own experimental/lightning-kmp submodule on branch `threshold`
-- the branch with the FROST/prefractal signers -- and substitutes
fr.acinq.lightning:lightning-kmp-core for that build's project. That build includes
bitcoin-kmp, which includes secp256k1-kmp, which compiles the C library from a secp256k1-zkp
fork. So this repo's build tree is now four levels deep and compiles native code.
Cloning therefore needs `git submodule update --init --recursive`, and because each included
build resolves the android SDK from its own local.properties rather than inheriting the
root's, the three new nested builds each need a (gitignored) local.properties with sdk.dir.
57353cf changed two signatures that MantraApplication implements -- LightningApplication
gained getApplicationContext(), and BusinessManager.initialize now takes the application
rather than a Context. Neither needed a source change: MantraApplication extends
android.app.Application, which already supplies getApplicationContext(), and it was already
passing `this`, which satisfies the narrowed parameter type.
The rest of this commit is what the update forces on the outer build.
gradle-wrapper.properties, 9.3.1 -> 9.7.1: f22c30a moved every build in the chain onto
9.7.1. An included build does not use its own wrapper -- the root build's gradle version runs
the whole tree -- so this repo has to follow for the chain to build at all.
gradle.properties, configuration cache off: secp256k1-kmp's `:jni:generateHeaders` and
`:native:buildSecp256k1<target>` both hold gradle script object references and cannot be
serialized. The configuration cache covers a whole build tree and has no per-build opt-out,
so an included build's incompatibility is this build's problem. The comment records how to
undo this once those tasks are fixed upstream.
composeApp/build.gradle.kts, ios targets gated on the host: secp256k1-kmp declares a
libsecp256k1 cinterop, which makes gradle switch off klib cross compilation for apple
targets. On linux nothing in the tree then offers an ios variant of
fr.acinq.phoenix:lightning-kmp-app, and the ios compilations failed with "No matching variant
of project ':lightning-kmp-app:library'" -- not a warning, a build failure. The gate covers
the target declarations, the iosMain dependencies (the source set only exists when the
targets do) and the kspIos* configurations (likewise). This mirrors bbba08b, which applied
the same gate inside the submodule for the same reason.
secp256k1-frost-kmp d3b294d applies that gate there too. Substitution rules apply across a
whole build tree, so that project's own lightning-kmp-core coordinate started resolving to
the source project without it asking, and every apple source set stopped resolving. The
android build masked it -- ios compilations are not in its task graph -- but
kmpPartiallyResolvedDependenciesChecker reported it and compileAppleMainKotlinMetadata failed
outright, which would have broken IDE import.
Note that `:composeApp:compileCommonMainKotlinMetadata` no longer exists on a linux host.
With ios gated off, androidTarget is the only declared target (jvm() is still commented out),
and KMP does not generate a commonMain metadata compilation for a single-target project.
`:composeApp:compileDebugKotlinAndroid` is the check now; it passes clean, with none of the
resolution errors above.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 22:50:59 +02:00
|
|
|
# Off because the lightning-kmp-app composite build reaches, through its experimental/lightning-kmp
|
|
|
|
|
# -> bitcoin-kmp -> secp256k1-kmp submodule chain, two tasks that cannot be serialized:
|
|
|
|
|
# secp256k1-kmp's `:jni:generateHeaders` and `:native:buildSecp256k1<target>` both hold gradle
|
|
|
|
|
# script object references. The configuration cache covers a whole build tree, so an included
|
|
|
|
|
# build's incompatibility is this build's problem -- there is no per-build opt-out. Re-enable once
|
|
|
|
|
# those two tasks are fixed upstream in the secp256k1-kmp fork, or if that includeBuild goes.
|
|
|
|
|
org.gradle.configuration-cache=false
|
2026-03-23 01:41:39 +02:00
|
|
|
org.gradle.caching=true
|
|
|
|
|
|
|
|
|
|
#Android
|
|
|
|
|
android.nonTransitiveRClass=true
|
2026-05-17 23:02:42 +02:00
|
|
|
android.useAndroidX=true
|
|
|
|
|
android.defaults.buildfeatures.resvalues=true
|
|
|
|
|
android.sdk.defaultTargetSdkToCompileSdkIfUnset=false
|
|
|
|
|
android.enableAppCompileTimeRClass=false
|
|
|
|
|
android.usesSdkInManifest.disallowed=false
|
|
|
|
|
android.uniquePackageNames=false
|
|
|
|
|
android.dependency.useConstraints=true
|
|
|
|
|
android.r8.strictFullModeForKeepRules=false
|
|
|
|
|
android.r8.optimizedResourceShrinking=false
|
|
|
|
|
android.builtInKotlin=false
|
|
|
|
|
android.newDsl=false
|