1This is the buildSrc project.
2Gradle builds (and tests) this project before the other projects, and Gradle adds its artifacts into the classpath of the other projects when configuring them.
3
4Tests for the buildSrc project are located in the buildSrc-tests project, so that the build doesn't need to wait for those tests to complete
5
6To run these tests you can run `./gradlew :buildSrc-tests:test`
7
8For information about Gradle's configuration caching, see:
9  *  https://medium.com/androiddevelopers/configuration-caching-deep-dive-bcb304698070
10  *  https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
11  *  https://github.com/gradle/gradle/issues/17813
12
13The buildSrc directory is split into multiple projects based on what needs to be available on the classpath when parsing build.gradle files outside of buildSrc.
14Any classes that Gradle puts on the classpath for parsing build.gradle files can theoretically overwrite the implementation of tasks in those projects.
15So, if a class is on that classpath and it changes, then Gradle is not confident that the task is necessarily up-to-date and Gradle will rerun it.
16So, we move as many classes as possible off of this classpath by applying them from within a separate .gradle script instead.
17
18To verify that classes in private/ don't unnecessarily affect the up-to-datedness status of tasks from outside plugins, try something like this:
19
20```
21  # run a kotlin compilation task
22  ./gradlew :core:core:compileDebugKotlin
23  # make some unrelated changes in buildSrc:
24  sed -i 's/ignoreCase = true/ignoreCase = false/g' buildSrc/private/src/main/kotlin/androidx/build/ErrorProneConfiguration.kt
25  # rerun same kotlin compilation task
26  ./gradlew :core:core:compileDebugKotlin | cat
27  # see that the tasks were up-to-date
28```
29
30See also b/140265324 for more information.
31