Consider a doc on this function that says we prefer the settings.gradle.kts over settings.gradle.

Also I think this might cause an issue for customers updating since they could have a settings.gradle.kts file that is being ignored and maybe is malformed and a flutter update would cause their build to break. Let me talk this over with @christopherfujino and the android team.

I added the doc comment.

Re: your concern – it is possible that a situation like that might happen, but I think this would be very rare case. Of course I have no data to back it up - I'm according to my experience and "gut feeling". Like, why would some developer end up with both settings.gradle.kts and settings.gradle?

Personally I wouldn't care about it (with my current state of knowledge).

Sorry but we have competing guts, I think it is likely to happen for customers who are mid migration and they wont realize that there are different behaviors. Unlike build.gradle and build.gradle.kts I dont think settings.gradle and settings.gradle.kts are mutually exclusive.

Either way our code should be clear on what we expect.

OK, I get you. Thanks for competing with my gut.

I tested Gradle's behavior when both settings.gradle.kts and settings.gradle exist:

build.gradle.kts

rootProject.name = "gradle-example-kts"
logger.quiet("Hello, the project name is: ${rootProject.name}")

build.gradle

rootProject.name = "gradle-example"
logger.quiet("Hello, the project name is: ${rootProject.name}")

Gradle completely ignores settings.gradle.kts:

$ gradle projects
Hello, the project name is: gradle-example

> Task :projects

------------------------------------------------------------
Root project 'gradle-example'
------------------------------------------------------------

Root project 'gradle-example'
No sub-projects

To see a list of the tasks of a project, run gradle <project-path>:tasks
For example, try running gradle :tasks

BUILD SUCCESSFUL in 391ms
1 actionable task: 1 executed

So I think we should follow Gradle's behavior (use Groovy even when Kotlin exists). I'd also print a warning (using logger.error()) since this seems unintuitive to me).

Tested on Gradle 8.5

The same thing happens for build.gradle.kts and build.gradle:

build.gradle.kts

tasks.register("hello-kotlin") {
    group = "fun"
    description = "Says hello from Kotlin"
    doLast {
        logger.quiet("Hello from Gradle KTS")
    }
}

build.gradle

tasks.register("hello-groovy") {
    group = "fun"
    description = "Says hello from Groovy"
    doLast {
        logger.quiet("Hello from Gradle Groovy")
    }
}

Running (some irrelevant output omitted):

$ gradle tasks
Fun tasks
---------
hello-groovy - Says hello from Groovy

Tested on Gradle 8.5

Thank you for testing, It does make sense that we would try to mirror gradles default behavior and I do think this is good evidence that we DO NOT prefer the kotlin file over the groovy file. I do think that a hard failure could still make sense but I think I have asked you to churn on this enough and we can change the behavior later if we made the wrong call.

I think either this variable should be removed and the logger strings below should have this inline or the logger strings should stay the same using the file object and rely on the if statement below to use set buildfile correctly

I went for a variable because that string occured in 3 logger.printTrace() statements and remembered rule-of-3.

I'll go with this:

the logger strings should stay the same using the file object and rely on the if statement below to use set buildfile correctly

I would also add logger.error() so that users who (for whatever weird reason) don't have a build.gradle/build.gradle.kts file will see red text when flutter building. Should this case even be supported? I doubt flutter app build works without these buildfiles.

Wdyt?

I wrote some of this code originally and I it is more likely that we have a bug in our code than that the users code does not match the conditions below.

Specifically the regular expressions assume a groovy style syntax. Can you file an issue and put it in a comment here that this code needs to be updated with regular expressions and tests that cover the kotlin case in addition to groovy?

I filed #141410 can you add a reference to that bug in this method?

If you mean specifically the _buildAndroidGradlePluginRegExp RegExp that is used in this method (getGradleVersionForAndroidPlugin()), then it works in both Groovy and Kotlin.

Please include in the dart doc the behavior if both build.gradle and build.gradle.kts are present.

done in d30b4da

this is a confusing comment. running that script won't update this anyway, right?

or will it, and is the user supposed to run that script then revert the change to this file? If so, I would recommend we update the script instead.

or will it, and is the user supposed to run that script then revert the change to this file?

That's right.

I created #140115 because changing the generate_gradle_lockfiles.dart script and running it is a quite massive change (see that PR's "lines changed"). That's why this comment exists.

in that case lets make the comment something closer to "This file is auto updated by dev/tools/bin/generate_gradle_lockfiles.dart, do not merge changes to this file. See #140115"

done in 90c07d3

in that case lets make the comment something closer to "This file is auto updated by dev/tools/bin/generate_gradle_lockfiles.dart, do not merge changes to this file. See #140115"

I wrote some of this code originally and I it is more likely that we have a bug in our code than that the users code does not match the conditions below.

Specifically the regular expressions assume a groovy style syntax. Can you file an issue and put it in a comment here that this code needs to be updated with regular expressions and tests that cover the kotlin case in addition to groovy?

@johnmccutchan @christopherfujino FYI new tool exit when a user has both kotlin and gradle build files.

Nope, not anymore (see 99929d7). Too many test failures resulted that would be out of scope of this PR. I'll file an issue to keep track of it and link to that issue from the code comment.

Based on that link and the code left in this pr my comment is still true. You removed the tool exit when neither was present. Which, if it cause test failures, I can understand removing. However we should not get test failures by enforcing that both build.gradle and build.gradle.kts should not exist at the same time.

Sorry, I misunderstood your comment.

I agree with everything you said in the above comment.

Sorry, I think I am still misunderstanding your comment. You are saying that after this change we DO tool exit if the user has both? Or DO NOT? (This line looks like we're silently preferring groovy.)

I made some changes after I wrote the comment above. Sorry again for the confusion!

Currently, we DO NOT crash/exit the tool when both build.gradle and build.gradle.kts exist. Instead, we use build.gradle and ignore build.gradle.kts (and the same goes for settings.gradle). This is consistent with Gradle's behavior.

To clarify, when I said

I think I am still misunderstanding your comment

I was referring to @reidbaker's first comment.