mozilla / rust-android-gradle

Apache License 2.0
1.03k stars 67 forks source link

Set cargo release profile for different buildTypes #38

Open ErikBjare opened 3 years ago

ErikBjare commented 3 years ago

I have two build types release and debug, and I'd like to set the cargo release profile depending on the build type (instead of using debug, which is bad in production, or using release, which is slow when developing or running in CI).

Example of my build types:

android {
    ...
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        debug {
            applicationIdSuffix ".debug"
        }
    }
}

I noticed that https://github.com/willir/cargo-ndk-android-gradle did what I want by default, and supported additional configuration per-buildType. Is there a way to work around this? Or is the fix to support it easy?

tmcguire commented 3 years ago

I use this as a workaround:

cargo {
    ...

    // There doesn't seem to be a simpler way to get the current buildType than to check the task names,
    // see https://stackoverflow.com/a/53261807/1005419.
    profile = gradle.startParameter.taskNames.any{it.toLowerCase().contains("debug")} ? "debug" : "release"
}

Note that this only works as long as there are only two build types, "debug" and "release", configured in the project.

ncalexan commented 3 years ago

Just from a general Gradle and Android-Gradle plugin perspective, this isn't particularly robust. If you can inspect the Gradle task execution graph (see https://docs.gradle.org/current/javadoc/org/gradle/api/execution/TaskExecutionGraph.html) then you can figure out which tasks are actually going to be run. That avoids invoking gradle foo and missing that foo depends on assembleDebug or whatever.

But overall you're witnessing an architecture mismatch between Cargo (which has a limited set of build profiles), the Android-Gradle plugin (which has a rich set of build types and product flavors), and this plugin, which doesn't set up tasks for each Android-Gradle configuration.

To fix this "properly" we'd need to do quite a bit more work to have per-Android-Gradle-configuration cargo tasks, each with their own configuration. That's been done -- I think Google's protobuf plugin at https://github.com/google/protobuf-gradle-plugin is my preferred example -- but it's a ton of work :(

ncalexan commented 3 years ago

I'm just making a note to myself that there are more Gradle plugins that allow build and product configuration to cult from these days, e.g. https://github.com/usefulness/easylauncher-gradle-plugin.