<commit_before>## New and noteworthy

Here are the new features introduced in this Gradle release.

### Generate Visual Studio configuration for a native binary project (i)

One of the great things about using Gradle for building Java projects is the ability to generate IDE configuration files: this
release of Gradle brings a similar feature when you use Microsoft Visual Studio as your IDE. With this integration, you can
use the best tool for the job: Gradle to build your binaries and Visual Studio to edit your code.

Visual Studio integration is supplied by the `visual-studio` plugin. When this plugin is applied, for each component
Gradle will create a task to produce a Visual Studio solution for a selected binary variant of that component.
The generated solution will include a project file for the selected binary, as well as project files for each depended-on library.

Similar to the Java IDE plugins, you can customize the generated Visual Studio configuration files with programmatic hooks.
These hooks are applied to the `visualStudio` element in the model registry.
For example, you can change the default locations of the generated files:

    model {
        visualStudio {
            solutions.all { VisualStudioSolution solution ->
                solutionFile.location = "vs/${solution.name}.sln"
            }
            projects.all { VisualStudioProject project ->
                projectFile.location = "vs/${project.name}.vcxproj"
                filtersFile.location = "vs/${project.name}.vcxproj.filters"
            }
        }
    }

Additionally, you can change the content of the generated files:

    model {
        visualStudio {
            solutions.all { VisualStudioSolution solution ->
                solutionFile.withText { StringBuilder text ->
                    ... customise the solution content
                }
            }
            projects.all { VisualStudioProject project ->
                projectFile.withXml { XmlProvider xml ->
                    xml.asNode()...
                }
            }
        }
    }


While Visual Studio support is functional, there remain some limitations:

- Macros defined by passing '/D' to compiler args are not included in your project configuration. Use 'cppCompiler.define' instead.
- Includes defined by passing '/I' to compiler args are not included in your project configuration. Use library dependencies instead.
- External dependencies supplied via `sourceSet.dependency` are not yet handled.

Please try it out an let us know how it works for you.

### Choose applicable platforms, build types and flavors for a native component (i)

It is now possible to specify a global set of build types, platforms and flavors and then specifically choose which of
these should apply for a particular component. This makes it easier to have a single plugin that adds support for a
bunch of platforms, build types, and/or flavors, and have the build script choose which of these are appropriate.

- `buildTypes` is now `model.buildTypes`
- `targetPlatforms` is now `model.platforms`
- `executable.flavors` or `library.flavors` is now `model.flavors`


    model {
        platforms {
            create('x86') {
                ... config
            }
        }
        buildTypes {
            create('debug')
        }
        flavors {
            create('my-flavor')
        }
        ... Many others, perhaps added by capability plugins
    }

    executables {
        main {
            targetPlatforms "x86" // Only build for this platform
            targetFlavors "foo", "bar" // Build these 2 flavors
            // targetBuildTypes - without this, all build types are targeted.
        }
    }

#### Current Limitations

The model registry and it's DSL are very new, and impose some DSL limitations. We plan to improve these in the future.

- Elements in containers under `model` must be added with the `create(name)` method.
- The `component.target*` methods match on element _name_. It is not possible to supply an element instance at this time.

### Better support for declaring library dependencies when building native binaries (i)

#### New dependency notation

When building native binaries, it is now possible to declare a dependency on a library by a dependency notation.

    executables {
        main {}
    }
    sources.main.cpp.lib library: 'hello', linkage: 'static'
    sources.main.c.lib project: ':another', library: 'hi'

    libraries {
        hello {}
    }

The 'project', 'library' and 'linkage' can be specified. Only 'library' is required and must be the name of a library
in the specified project, or in the current project if the 'project' attribute is omitted.

This notation based syntax provides a number of benefits over directly accessing the library when declaring the dependency requirement:

- The library referenced does not have to be declared before the dependency declaration in the build script
- For libraries in another project, the depended-on project does not need to have been evaluated when the dependency declaration is added
- The linkage is clearly specified

#### Support for header-only libraries

#### Support for api dependencies

There are times when your source may require the headers of a library at compile time, but not require the library binary when linking.
To support this use case, it is now possible to add a dependency on the 'api' linkage of a library. In this case, the headers
of the library will be available when compiling, but no binary will be provided when linking.

A dependency on the 'api' linkage can be specified by both the direct and the map-based syntax.

    sources.main.cpp.lib project: ':A', library: 'my-lib', linkage: 'api'
    sources.main.cpp.lib libraries.hello.api

#### Support for pre-built libraries

It would be very unusual for a sophisticated software project not to make some use of 3rd party system libraries.
In some cases these libraries are already available locally. This version of Gradle makes it possible to reference
these 'pre-built' libraries such that they can be referenced as a dependency in the same way as libraries built by
Gradle.

In order to reference pre-built libraries, they must be added to a local repository of type `PrebuiltLibraries`.
For each library, the header directories to include can be defined, as well as the actual binary files for
static and shared library linkages.

    model {
        repositories {
            libs(PrebuiltLibraries) {
                create("boost-headers") {
                    headers.srcDir "libs/boost_1_55_0/boost"
                }
                create("util") {
                    headers.srcDir "libs/util/src/include"
                    binaries.withType(StaticLibraryBinary) {
                        staticLibraryFile = file("libs/util/bin/libutil.a")
                    }
                    binaries.withType(SharedLibraryBinary) {
                        sharedLibraryFile = file("libs/util/bin/libutil.so")
                    }<commit_msg>Some release note updates.<commit_after>## New and noteworthy

Here are the new features introduced in this Gradle release.

### Generate Visual Studio configuration for a native binary project (i)

One of the great things about using Gradle for building Java projects is the ability to generate IDE configuration files: this
release of Gradle brings a similar feature when you use Microsoft Visual Studio as your IDE. With this integration, you can
use the best tool for the job: Gradle to build your binaries and Visual Studio to edit your code.

Visual Studio integration is supplied by the `visual-studio` plugin. When this plugin is applied, for each component
Gradle will create a task to produce a Visual Studio solution for a selected binary variant of that component.
The generated solution will include a project file for the selected binary, as well as project files for each depended-on library.

Similar to the Java IDE plugins, you can customize the generated Visual Studio configuration files with programmatic hooks.
These hooks are applied to the `visualStudio` element in the model registry.
For example, you can change the default locations of the generated files:

    model {
        visualStudio {
            solutions.all { VisualStudioSolution solution ->
                solutionFile.location = "vs/${solution.name}.sln"
            }
            projects.all { VisualStudioProject project ->
                projectFile.location = "vs/${project.name}.vcxproj"
                filtersFile.location = "vs/${project.name}.vcxproj.filters"
            }
        }
    }

Additionally, you can change the content of the generated files:

    model {
        visualStudio {
            solutions.all { VisualStudioSolution solution ->
                solutionFile.withText { StringBuilder text ->
                    ... customise the solution content
                }
            }
            projects.all { VisualStudioProject project ->
                projectFile.withXml { XmlProvider xml ->
                    xml.asNode()...
                }
            }
        }
    }


While Visual Studio support is functional, there remain some limitations:

- Macros defined by passing `/D` to compiler args are not included in your project configuration. Use `cppCompiler.define` instead.
- Includes defined by passing `/I` to compiler args are not included in your project configuration. Use library dependencies instead.
- External dependencies supplied via `sourceSet.dependency` are not yet handled.

Please try it out an let us know how it works for you.

### Choose applicable platforms, build types and flavors for a native component (i)

It is now possible to specify a global set of build types, platforms and flavors and then specifically choose which of
these should apply for a particular component. This makes it easier to have a single plugin that adds support for a
bunch of platforms, build types, and/or flavors, and have the build script choose which of these are appropriate.

- `buildTypes` is now `model.buildTypes`
- `targetPlatforms` is now `model.platforms`
- `executable.flavors` or `library.flavors` is now `model.flavors`


    model {
        platforms {
            x86 {
                ... config
            }
        }
        buildTypes {
            debug
        }
        flavors {
            custom
        }
        ... Many others, perhaps added by capability plugins
    }

    executables {
        main {
            targetPlatforms "x86" // Only build for this platform
            targetFlavors "foo", "bar" // Build these 2 flavors
            // targetBuildTypes - without this, all build types are targeted.
        }
    }

#### Current Limitations

The `model { }` DSL is very new, and imposes some DSL limitations. We plan to improve these in the future.

- The `component.target*` methods match on element _name_. It is not possible to supply an element instance at this time.

### Better support for declaring library dependencies when building native binaries (i)

#### New dependency notation

When building native binaries, it is now possible to declare a dependency on a library by a dependency notation.

    libraries {
        hello
    }

    executables {
        main
    }
    sources {
        main {
            cpp {
                lib library: 'hello', linkage: 'static'
            }
            c {
                lib project: ':another', library: 'hi'
            }
        }
    }

The `project`, `library` and `linkage` attributes can be specified. Only `library` is required and must be the name of a library
in the specified project, or in the current project if the `project` attribute is omitted.

This notation based syntax provides a number of benefits over directly accessing the library when declaring the dependency requirement:

- The library referenced does not have to be declared before the dependency declaration in the build script
- For libraries in another project, the depended-on project does not need to have been evaluated when the dependency declaration is added
- The linkage is clearly specified

#### Support for header-only libraries

#### Support for api dependencies

There are times when your source may require the headers of a library at compile time, but not require the library binary when linking.
To support this use case, it is now possible to add a dependency on the 'api' linkage of a library. In this case, the headers
of the library will be available when compiling, but no binary will be provided when linking.

A dependency on the 'api' linkage can be specified by both the direct and the map-based syntax.

    sources {
        main {
            cpp {
                lib project: ':A', library: 'my-lib', linkage: 'api'
                lib libraries.hello.api
            }
        }
    }

#### Support for pre-built libraries

It would be very unusual for a sophisticated software project not to make some use of 3rd party system libraries.
In some cases these libraries are already available locally. This version of Gradle makes it possible to reference
these 'pre-built' libraries such that they can be referenced as a dependency in the same way as libraries built by
Gradle.

In order to reference pre-built libraries, they must be added to a local repository of type `PrebuiltLibraries`.
For each library, the header directories to include can be defined, as well as the actual binary files for
static and shared library linkages.

    model {
        repositories {
            libs(PrebuiltLibraries) {
                boost {
                    headers.srcDir "libs/boost_1_55_0/boost"
                }
                util {
                    headers.srcDir "libs/util/src/include"
                    binaries.withType(StaticLibraryBinary) {
                        staticLibraryFile = file("libs/util/bin/libutil.a")
                    }
                    binaries.withType(SharedLibraryBinary) {
                        sharedLibraryFile = file("libs/util/bin/libutil.so")
                    }
{'fraction_non_alphanumeric': 0.057746878547105564, 'fraction_numerical': 0.0014188422247446084, 'mean_word_length': 2.598927750829717, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 4}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2878591', 'n_tokens_mistral': 3376, 'n_tokens_neox': 3182, 'n_words': 1672}