}

rootProject.name = 'tutorial'
include('app')
----
=====

The `tutorial` root project includes the `app` subproject.
The presence of the `include` call turns the `app` directory into a subproject.

== Step 7. Understanding the Build script
Each subproject contains its own `build.gradle(.kts)` file.

            ProjectRegistry<ProjectInternal> projectRegistry = Cast.uncheckedCast(serviceRegistry.get(DefaultProjectRegistry.class));

            for (ProjectInternal subproject : projectRegistry.getSubProjects(projectIdentifier.getPath())) {
                projectModelResolver.resolveProjectModel(subproject.getPath()).find("visualStudio", VisualStudioExtension.class);
            }
        }
    }

====
include::sample[dir="kotlin",files="buildSrc/src/main/kotlin/myproject.java-conventions.gradle.kts[tags=toolchain]"]
include::sample[dir="groovy",files="buildSrc/src/main/groovy/myproject.java-conventions.gradle[tags=toolchain]"]
====

While most modules are fine with the defaults, the `list` subproject overrides the defaults as it has more specific requirements.

====

    @IntegrationTestTimeout(value = 60, onlyIf = { GradleContextualExecuter.embedded })
    def "can query dependencies with configure on demand enabled"() {
        def subprojects = ["a", "b"]
        multiProjectBuild("outputRegistry", subprojects)
        subprojects.each { projectName ->
            file("${projectName}/build.gradle") << """
                plugins {
                    id("java-library")
                }

<4> Settings file to define build name and subprojects
<5> Build script of _buildSrc_ to configure dependencies of the build logic
<6> Source folder for _convention plugins_ written in Groovy or Kotlin DSL
<7> Build script of the three subprojects - `app`, `list` and `utilities`
<8> ${language.raw} source folders in each of the subprojects
<9> ${language.raw} test source folders in the subprojects

        subproject("base-asm")
        subproject("base-services")
        subproject("build-configuration")
        subproject("build-operations")
        subproject("build-option")
        subproject("build-process-services")
        subproject("build-profile")
        subproject("build-state")
        subproject("cli")
        subproject("client-services")
        subproject("concurrent")
        subproject("daemon-main")

        buildType(stagePasses)
        subProject(stageProject)

        prevStage = stage
        previousPerformanceTestPasses.addAll(stageProject.performanceTests)
    }

    buildType(GitHubMergeQueueCheckPass(model))

    buildTypesOrder = buildTypes
    subProjectsOrder = subProjects

    cleanupRule(
        historyDays = 14,
        artifactsDays = 7,

- `include("${subprojectName.raw}")` defines that the build consists of one subproject called `${subprojectName.raw}` that contains the actual code and build logic.
  More subprojects can be added by additional `include(...)` statements.

Our build contains one subproject called `${subprojectName.raw}` that represents the ${language.raw} ${componentType.raw} we are building.

BUILD SUCCESSFUL in 1s
16 actionable tasks: 5 executed, 11 up-to-date
----

So far, we have looked at tasks in individual subprojects, which is useful for local development when you work on code in one subproject.

With this setup, developers only need to know that they can call Gradle with `:subproject-name:tasks` to see which tasks are available and useful for them.

[[sec:global_lifecycle_tasks]]
== Global lifecycle tasks

If your build includes multiple subprojects, create tasks to build those subprojects
independently. This helps you get the most out of caching, since a change to one
subproject won't force a rebuild for unrelated subprojects. And this helps reduce
build times for teams that work on unrelated subprojects: there's no need for
front-end developers to build the back-end subprojects every time they change the