anchor.diff:  Gradle select the first tool chain that can build for the target operating system and architecture.
   In the future, Gradle will consider source and ABI compatibility when selecting a tool chain.
   
  -Gradle has general support for the three major tool chains on major operating system: Clang footnote:[Installed with Xcode on macOS], GCC footnote:[Installed through Cygwin and MinGW for 32- and 64-bits architecture on Windows] and Visual C++ footnote:[Installed with Visual Studio 2010 to 2017] (Windows-only).
  +Gradle has general support for the three major tool chains on major operating system: Clang footnote:[Installed with Xcode on macOS], GCC footnote:[Installed through Cygwin and MinGW for 32- and 64-bits architecture on Windows] and Visual {cpp} footnote:[Installed with Visual Studio 2010 to 2017] (Windows-only).
   GCC and Clang installed using Macports and Homebrew have been reported to work fine, but this isn’t tested continuously.
   
   ==== Windows
   
   To build on Windows, install a compatible version of Visual Studio[4].
  -The C++ plugins will discover the Visual Studio installations and select the latest version.
  +The {cpp} plugins will discover the Visual Studio installations and select the latest version.
   There is no need to mess around with environment variables or batch scripts.
   This works fine from a Cygwin shell or the Windows command-line.
   
  
positive.code: Each component script block, as well as each binary, defines where it’s source code resides.
  You can override the convention values by using the following syntax:
  
  .Setting C++ source set
  ====
  include::sample[dir="userguide/cpp/basic/groovy",files="build.gradle[tags=cpp-source-set]"]
  include::sample[dir="userguide/cpp/basic/kotlin",files="build.gradle.kts[tags=cpp-source-set]"]
  
negative.code: [[sec:cpp_source_sets]]
  == Declaring your source files
  
  Gradle’s {cpp} support uses a `ConfigurableFileCollection` directly from the link:{groovyDslPath}/org.gradle.language.cpp.CppApplication.html[application] or link:{groovyDslPath}/org.gradle.language.cpp.CppLibrary.html[library] script block to configure the set of sources to compile.
  
  Libraries make a distinction between private (implementation details) and public (exported to consumer) headers. 
  
  You can also configure sources for each binary build for those cases where sources are compiled only on certain target machines.
  
  .Sources and {cpp} compilation
  image::cpp-sourcesets-compilation.png[]
  
  Test sources are configured on each test suite script block. See <<cpp_testing.adoc#,Testing {cpp} projects>> chapter.
  
  [[sec:cpp_dependency_management_overview]]
  == Managing your dependencies
  
  The vast majority of projects rely on other projects, so managing your project's dependencies is an important part of building any project.
  Dependency management is a big topic, so we will only focus on the basics for {cpp} projects here.
  If you’d like to dive into the details, check out the <<introduction_dependency_management.adoc#introduction_dependency_management,introduction to dependency management>>.
  
  Gradle provides support for consuming pre-built binaries from Maven repositories published by Gradle footnote:[Unfortunately, Conan and Nuget repositories aren’t yet support as core features]. 
  
  We will cover how to add dependencies between projects within a multi-build project.
  
  Specifying dependencies for your {cpp} project requires two pieces of information:
  
   * Identifying information for the dependency (project path, Maven GAV)
   * What it’s needed for, e.g. compilation, linking, runtime or all of the above.
  
  This information is specified in a `dependencies {}` block of the {cpp} `application` or `library` script block.
  For example, to tell Gradle that your project requires library `common` to compile and link your production code, you can use the following fragment:
  
  .Declaring dependencies
  