Skip to content

Conversation

@souvlakias
Copy link
Contributor

@souvlakias souvlakias commented Nov 7, 2025

Resolves #6141

Motivation

  • BuildConfig was an additional trait to be extended only by AndroidAppModules, but regular Modules should have it as well
  • Missing package field in the generated config
  • There was no task to add custom fields

Changes

  • Moved BuildConfig generation to AndroidModule.
    • It is configurable with the enableBuildConfig flag, which defaults to true (like gradle's).
  • Added package name that defaults to androidNamespace
  • Added a task for the config's members. (e.g. AndroidAppModule overrides this to add its applicationID

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this get marked as deprecated instead?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was experimental, so we can avoid duplications. But remember to update the examples

def androidBuildConfigMembers: T[Seq[String]] = Task {
val buildType = if (androidIsDebug()) "debug" else "release"
Seq(
s"boolean DEBUG = ${androidIsDebug()}",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would having a Map[String,Any] and then parse it, be better?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's ok for now, but ; are missing from what I see

@souvlakias
Copy link
Contributor Author

Some thoughts

Like in the case of viewBinding - in order to avoid having many traits - we override the generated sources based on a boolean flag. Since viewBinding is in AndroidKotlinModule there was no conflicts with BuildConfig, but if we were to support all BuildFeatures flags, things would get messy with this simple override.

I don't know if having a task like

override def generatedSources: T[Seq[PathRef]] = Task{
  super.generatedSources() ++
    Task.traverse(Seq(
        (androidGeneratedBuildConfigSources, enableBuildConfig),
		// More (task, boolean) tuples
      )) {
        case (task, enabled) =>
          if (enabled) task else Task.Anon(Seq.empty)
      }().flatten
}

(or something easier 😅) would be something that made sense.

@vaslabs
Copy link
Contributor

vaslabs commented Nov 11, 2025

lgtm

@souvlakias souvlakias marked this pull request as ready for review November 11, 2025 14:21
@souvlakias souvlakias marked this pull request as draft November 12, 2025 10:05
Copy link
Contributor

@vaslabs vaslabs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

waiting for some build config fixes

@souvlakias
Copy link
Contributor Author

souvlakias commented Nov 12, 2025

BuildConfigs for normal (non-app) modules have different fields. (e.g. LIBRARY_PACKAGE_NAME vs APPLICATION_ID)
image
Ref: https://android.googlesource.com/platform/tools/base/+/refs/heads/studio-master-dev/build-system/gradle-core/src/main/java/com/android/build/gradle/tasks/GenerateBuildConfig.kt#116

@souvlakias souvlakias marked this pull request as ready for review November 12, 2025 11:54
@lihaoyi lihaoyi merged commit 733502f into com-lihaoyi:main Nov 12, 2025
44 checks passed
@lefou lefou added this to the 1.1.0 milestone Nov 13, 2025
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

Successfully merging this pull request may close these issues.

Android: AndroidBuildConfig issues

4 participants