如何被配置的问题时，根目录的build.gradle文件应该是需要查看的。
Another thing to bear in mind is that the build files might not be called build.gradle. Many projects will name the build files after the subproject names, such asapi.gradle and services.gradle from the previous example. Such an approach helps a lot in IDEs because it’s tough to work out which build.gradle file out of twenty possibilities is the one you want to open. This little piece of magic is handled by the settings.gradle file, but as a build user you don’t need to know the details of how it’s done. Just have a look through the child project directories to find the files with the .gradle suffix.
//另一个事需要了解的是，build文件可能不叫build.gradle.很多工程会自己命名子工程下的build文件，例如上面例子中的api.gradle 和 services.gradle.这种方法帮了IDE很大的忙，因为让ide从20多重可能的文件中找到你想要打开的那个build文件是艰难的。这个处理逻辑在setting.gradle文件中。
Once you know what subprojects are available, the key question for a build user is how to execute the tasks within the project.
8.2. Executing a multi-project build
From a user's perspective, multi-project builds are still collections of tasks you can run. The difference is that you may want to control which project's tasks get executed. You have two options here:
//从用户的角度看，多工程构建仍然是一堆你可以运行的任务的集合。不同的是，你可能想去控制哪个工程的任务来执行，这里你有两个选项：
-
Change to the directory corresponding to the subproject you’re interested in and just execute gradle <task> as normal. //切换目录到需要构建的子工程目录下，然后像正常情况一样执行gradle <task>
-
Use a qualified task name from any directory, although this is usually done from the root. For example: gradle :services:webservice:build will build the webservicesubproject and any subprojects it depends on. //在任何目录下使用全称的任务名
The first approach is similar to the single-project use case, but Gradle works slightly differently in the case of a multi-project build. The command gradle test will execute the test task in any subprojects, relative to the current working directory, that have that task. So if you run the command from the root project directory, you’ll run test inapi, shared, services:shared and services:webservice. If you run the command from the services project directory, you’ll only execute the task in services:shared andservices:webservice.
//第一种方法和在只有一个工程的项目中使用方法是相似的，但是在多工程的项目中gradle的操作会有一些不同。命令gradle test将会执行所有子工程中的test任务，相对于当前的工作目录并且有test任务的都会执行。所以，如果你在根目录运行这个命令，你将会运行在api,shared,services：shared,services:webservice中的test任务，如果你在setvices工程目录中运行这个命令，你将只会执行在servics:shared和service:webservice中的test任务
For more control over what gets executed, use qualified names (the second approach mentioned). These are paths just like directory paths, but use ‘:’ instead of ‘/’ or ‘\’. If the path begins with a ‘:’, then the path is resolved relative to the root project. In other words, the leading ‘:’ represents the root project itself. All other colons are path separators.
//想要更高级的控制执行的内容，使用全称名字（上面提到的第二种办法）。有一些像目录路径一样的路径信息，但是使用冒号：而不是/,如果路径以：开头，那么这个路径就是相对根工程而言的，换句话说，开头的：代表根工程它自己。所有其他的冒号表示的是路径下划线。
This approach works for any task, so if you want to know what tasks are in a particular subproject, just use the tasks task, e.g. gradle :services:webservice:tasks .
//这个方法适用于所有的任务。如果你想知道在某一个特定子工程中