Splitting buildSrc sources into multiple directories
the first step towards multiple projects, multiple plugins, and multiple classpaths containing classes in buildSrc.
This will eventually mean that changes in buildSrc/impl won't need to invalidate the execution of tasks coming from externally applied plugins
Bug: 140265324
Test: Treehugger runs busytown/androidx.sh
Change-Id: I81af10d448c3d7a4055992e55b461b6ba986a258
diff --git a/buildSrc/README.md b/buildSrc/README.md
index 32e6c3d..4d251a3 100644
--- a/buildSrc/README.md
+++ b/buildSrc/README.md
@@ -9,3 +9,7 @@
* https://medium.com/androiddevelopers/configuration-caching-deep-dive-bcb304698070
* https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
* https://github.com/gradle/gradle/issues/17813
+
+The 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. Any classes that Gradle puts on the classpath for parsing build.gradle files can theoretically overwrite the implementation of tasks in those projects. So, 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. So, we move as many classes as possible off of this classpath by applying them from within a separate .gradle script instead.
+
+See also b/140265324 for more information.
