<commit_before><chapter id='nativeBinaries'>
    <title>Building native binaries</title>

    <note>
        <para>
            The Gradle support for building native binaries is currently <link linkend="feature_lifecycle">incubating</link>. Please be aware that the DSL and other configuration may change in later Gradle versions.
        </para>
    </note>

    <para>
        The various native binary plugins add support for building native software components, such as executables
        or shared libraries, from code written in C++, C and other languages. While many excellent build tools exist
        for this space of software development, Gradle offers developers its trademark power and flexibility
        together with dependency management practices more traditionally found in the JVM development space.
    </para>

    <section>
        <title>Supported languages</title>
        <para>
            The following source languages are currently supported:
        </para>
        <itemizedlist>
            <listitem><para>C</para></listitem>
            <listitem><para>C++</para></listitem>
            <listitem><para>Objective-C</para></listitem>
            <listitem><para>Objective-C++</para></listitem>
            <listitem><para>Assembly</para></listitem>
            <listitem><para>Windows resources</para></listitem>
        </itemizedlist>
    </section>

    <section id="native-binaries:tool-chain-support">
        <title>Tool chain support</title>
        <para>
            Gradle offers the ability to execute the same build using different tool chains. When you build a native binary, Gradle will attempt to locate a
            tool chain installed on your machine that can build the binary. You can fine tune exactly how this works,
            see <xref linkend="native_binaries:tool_chain"/> for details.
        </para>
        <para>
            The following tool chains are supported:
        </para>
        <table>
            <thead>
                <tr><td>Operating System</td><td>Tool Chain</td><td>Notes</td></tr>
            </thead>
            <tr>
                <td>Linux</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink></td> <td></td>
            </tr>
            <tr>
                <td>Linux</td><td><ulink url="http://clang.llvm.org">Clang</ulink></td><td></td>
            </tr>
            <tr>
                <td>Mac OS X</td><td>XCode</td><td>Uses the Clang tool chain bundled with XCode.</td>
            </tr>
            <tr>
                <td>Windows</td><td><ulink url="http://www.microsoft.com/visualstudio/en-us">Visual C++</ulink></td><td>Windows XP and later, Visual C++ 2010 and later.</td>
            </tr>
            <tr>
                <td>Windows</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink> with <ulink url="http://cygwin.com">Cywin 32</ulink></td><td>Windows XP and later.</td>
            </tr>
            <tr>
                <td>Windows</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink> with <ulink url="http://www.mingw.org/">MinGW</ulink></td><td>Windows XP and later. <ulink url="http://mingw-w64.sourceforge.net">Mingw-w64</ulink> is currently not supported.</td>
            </tr>
        </table>
        <para>
            The following tool chains are unofficially supported. They generally work fine, but are not tested continuously:
        </para>
        <table>
            <thead>
                <tr><td>Operating System</td><td>Tool Chain</td><td>Notes</td></tr>
            </thead>
            <tr>
                <td>Mac OS X</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink> from Macports</td><td></td>
            </tr>
            <tr>
                <td>Mac OS X</td><td><ulink url="http://clang.llvm.org">Clang</ulink> from Macports</td><td></td>
            </tr>
            <tr>
                <td>Windows</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink> with <ulink url="http://cygwin.com">Cywin 64</ulink></td><td>Windows XP and later.</td>
            </tr>
            <tr>
                <td>UNIX-like</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink></td><td></td>
            </tr>
            <tr>
                <td>UNIX-like</td><td><ulink url="http://clang.llvm.org">Clang</ulink></td><td></td>
            </tr>
        </table>
    </section>
    <section>
        <title>Tool chain installation</title>
        <note>
            <para>
                Note that if you are using GCC then you currently need to install support for C++, even if you are not building from C++ source. This caveat will be removed in a future Gradle version.
            </para>
        </note>
        <para>To build native binaries, you will need to have a compatible tool chain installed:
        </para>
        <section>
            <title>Windows</title>
            <para>To build on Windows, install a compatible version of Visual Studio. The native 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.
            </para>
            <para>Alternatively, you can install Cygwin with GCC or MinGW. Clang is currently not supported.</para>
        </section>
        <section>
            <title>OS X</title>
            <para>To build on OS X, you should install XCode. The native plugins will discover the XCode installation using the system PATH.
            </para>
            <para>
                The native plugins also work with GCC and Clang bundled with Macports. To use one of the Macports tool chains,
                you will need to make the tool chain the default using the <userinput>port select</userinput> command and add Macports to the system PATH.
            </para>
        </section>
        <section>
            <title>Linux</title>
            <para>To build on Linux, install a compatible version of GCC or Clang. The native plugins will discover GCC or Clang using the system PATH.
            </para>
        </section>
    </section>

    <section>
        <title>Component model</title>
        <para>
            To build native binaries using Gradle, your project should define one or more <firstterm>native components</firstterm>. Each component represents either an
            executable or a library that Gradle should build. A project can define any number of components. Gradle does not define any components by default.
        </para>
        <para>
            For each component, Gradle defines a <firstterm>source set</firstterm> for each language that the component can be built from. A source set is essentially
            just a set of source directories containing source files. For example, when you apply the <literal>c</literal> plugin and define a library called
            <literal>helloworld</literal>, Gradle will define, by default, a source set containing the C source files in the <literal>src/helloworld/c</literal> directory.
            It will use these source files to build the <literal>helloworld</literal> library.
            This is described in more detail below.
        </para>
        <para>
            For each component, Gradle defines one or more <firstterm>binaries</firstterm> as output. To build a binary, Gradle will take the source files defined for
            the component, compile them as appropriate for the source language, and link the result into a binary file. For an executable component, Gradle can
            produce executable binary files. For a library component, Gradle can produce both static and shared library binary files. For example, when you define
            a library called <literal>helloworld</literal> and build on Linux, Gradle will, by default, produce <filename>libhelloworld.so</filename> and
            <filename>libhelloworld.a</filename> binaries.
        </para>
        <para>
            In many cases, more than one binary can be produced for a component.
            These binaries may vary based on the tool chain used to build, the compiler/linker flags supplied, the dependencies
            provided, or additional source files provided. Each native binary produced for a component is referred to as <firstterm>variant</firstterm>.
            Binary variants are discussed in detail below.
        </para>
    </section>

    <section>
        <title>Parallel Compilation</title>
        <para>
            Gradle uses parallel compilation when building native components. All sources in a single source set are divided up among several workers.  No special
            configuration is required to turn on this behavior.
        </para>
        <para>
            You can change the number of background workers that Gradle will use when compiling and linking. By default, Gradle will try to use the same number of workers
            as there are available processors.  To explicitly set the number of workers use the command-line option <literal>--max-workers</literal> or the
            <literal>org.gradle.workers.max</literal> system property.  We do not expect that you will usually need to adjust this setting.
        </para>
        <para>
            Since Gradle does not run tasks in parallel from the same project, increasing the number of workers will not have much impact on single-project builds, even if you
            have several separate native components.  If your build is a multi-project build that runs with <literal>--parallel</literal>, the workers are pooled and shared across
            project boundaries.  So if workers is set to five and ten projects are building in parallel, Gradle will only use five total workers, not fifty.
        </para>
    </section>
    <section>
        <title>Building a library</title>
        <para>
            To build either a static or shared native library, you define a library component in the <literal>components</literal> container. The following sample<commit_msg>Reword user guide docs about --max-workers<commit_after><chapter id='nativeBinaries'>
    <title>Building native binaries</title>

    <note>
        <para>
            The Gradle support for building native binaries is currently <link linkend="feature_lifecycle">incubating</link>. Please be aware that the DSL and other configuration may change in later Gradle versions.
        </para>
    </note>

    <para>
        The various native binary plugins add support for building native software components, such as executables
        or shared libraries, from code written in C++, C and other languages. While many excellent build tools exist
        for this space of software development, Gradle offers developers its trademark power and flexibility
        together with dependency management practices more traditionally found in the JVM development space.
    </para>

    <section>
        <title>Supported languages</title>
        <para>
            The following source languages are currently supported:
        </para>
        <itemizedlist>
            <listitem><para>C</para></listitem>
            <listitem><para>C++</para></listitem>
            <listitem><para>Objective-C</para></listitem>
            <listitem><para>Objective-C++</para></listitem>
            <listitem><para>Assembly</para></listitem>
            <listitem><para>Windows resources</para></listitem>
        </itemizedlist>
    </section>

    <section id="native-binaries:tool-chain-support">
        <title>Tool chain support</title>
        <para>
            Gradle offers the ability to execute the same build using different tool chains. When you build a native binary, Gradle will attempt to locate a
            tool chain installed on your machine that can build the binary. You can fine tune exactly how this works,
            see <xref linkend="native_binaries:tool_chain"/> for details.
        </para>
        <para>
            The following tool chains are supported:
        </para>
        <table>
            <thead>
                <tr><td>Operating System</td><td>Tool Chain</td><td>Notes</td></tr>
            </thead>
            <tr>
                <td>Linux</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink></td> <td></td>
            </tr>
            <tr>
                <td>Linux</td><td><ulink url="http://clang.llvm.org">Clang</ulink></td><td></td>
            </tr>
            <tr>
                <td>Mac OS X</td><td>XCode</td><td>Uses the Clang tool chain bundled with XCode.</td>
            </tr>
            <tr>
                <td>Windows</td><td><ulink url="http://www.microsoft.com/visualstudio/en-us">Visual C++</ulink></td><td>Windows XP and later, Visual C++ 2010 and later.</td>
            </tr>
            <tr>
                <td>Windows</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink> with <ulink url="http://cygwin.com">Cywin 32</ulink></td><td>Windows XP and later.</td>
            </tr>
            <tr>
                <td>Windows</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink> with <ulink url="http://www.mingw.org/">MinGW</ulink></td><td>Windows XP and later. <ulink url="http://mingw-w64.sourceforge.net">Mingw-w64</ulink> is currently not supported.</td>
            </tr>
        </table>
        <para>
            The following tool chains are unofficially supported. They generally work fine, but are not tested continuously:
        </para>
        <table>
            <thead>
                <tr><td>Operating System</td><td>Tool Chain</td><td>Notes</td></tr>
            </thead>
            <tr>
                <td>Mac OS X</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink> from Macports</td><td></td>
            </tr>
            <tr>
                <td>Mac OS X</td><td><ulink url="http://clang.llvm.org">Clang</ulink> from Macports</td><td></td>
            </tr>
            <tr>
                <td>Windows</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink> with <ulink url="http://cygwin.com">Cywin 64</ulink></td><td>Windows XP and later.</td>
            </tr>
            <tr>
                <td>UNIX-like</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink></td><td></td>
            </tr>
            <tr>
                <td>UNIX-like</td><td><ulink url="http://clang.llvm.org">Clang</ulink></td><td></td>
            </tr>
        </table>
    </section>
    <section>
        <title>Tool chain installation</title>
        <note>
            <para>
                Note that if you are using GCC then you currently need to install support for C++, even if you are not building from C++ source. This caveat will be removed in a future Gradle version.
            </para>
        </note>
        <para>To build native binaries, you will need to have a compatible tool chain installed:
        </para>
        <section>
            <title>Windows</title>
            <para>To build on Windows, install a compatible version of Visual Studio. The native 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.
            </para>
            <para>Alternatively, you can install Cygwin with GCC or MinGW. Clang is currently not supported.</para>
        </section>
        <section>
            <title>OS X</title>
            <para>To build on OS X, you should install XCode. The native plugins will discover the XCode installation using the system PATH.
            </para>
            <para>
                The native plugins also work with GCC and Clang bundled with Macports. To use one of the Macports tool chains,
                you will need to make the tool chain the default using the <userinput>port select</userinput> command and add Macports to the system PATH.
            </para>
        </section>
        <section>
            <title>Linux</title>
            <para>To build on Linux, install a compatible version of GCC or Clang. The native plugins will discover GCC or Clang using the system PATH.
            </para>
        </section>
    </section>

    <section>
        <title>Component model</title>
        <para>
            To build native binaries using Gradle, your project should define one or more <firstterm>native components</firstterm>. Each component represents either an
            executable or a library that Gradle should build. A project can define any number of components. Gradle does not define any components by default.
        </para>
        <para>
            For each component, Gradle defines a <firstterm>source set</firstterm> for each language that the component can be built from. A source set is essentially
            just a set of source directories containing source files. For example, when you apply the <literal>c</literal> plugin and define a library called
            <literal>helloworld</literal>, Gradle will define, by default, a source set containing the C source files in the <literal>src/helloworld/c</literal> directory.
            It will use these source files to build the <literal>helloworld</literal> library.
            This is described in more detail below.
        </para>
        <para>
            For each component, Gradle defines one or more <firstterm>binaries</firstterm> as output. To build a binary, Gradle will take the source files defined for
            the component, compile them as appropriate for the source language, and link the result into a binary file. For an executable component, Gradle can
            produce executable binary files. For a library component, Gradle can produce both static and shared library binary files. For example, when you define
            a library called <literal>helloworld</literal> and build on Linux, Gradle will, by default, produce <filename>libhelloworld.so</filename> and
            <filename>libhelloworld.a</filename> binaries.
        </para>
        <para>
            In many cases, more than one binary can be produced for a component.
            These binaries may vary based on the tool chain used to build, the compiler/linker flags supplied, the dependencies
            provided, or additional source files provided. Each native binary produced for a component is referred to as <firstterm>variant</firstterm>.
            Binary variants are discussed in detail below.
        </para>
    </section>

    <section>
        <title>Parallel Compilation</title>
        <para>
            Gradle uses parallel compilation when building native components. All sources in a single source set are divided up among several workers.  No special
            configuration is required to turn on this behavior.
        </para>
        <para>
            You can change the number of background workers that Gradle will use when compiling and linking. By default, Gradle will try to use the same number of workers
            as there are available processors.  To explicitly set the number of workers use the command-line option <literal>--max-workers</literal> or the
            <literal>org.gradle.workers.max</literal> system property.  We do not expect that you will usually need to adjust this setting.
        </para>
        <para>
            If your build is a multi-project build that runs with <literal>--parallel</literal>, Gradle pools the workers and shares them across project boundaries.  
            So if workers is set to five and ten projects are compiling in parallel, Gradle will only use five total workers, not fifty.
        </para>
    </section>
    <section>
        <title>Building a library</title>
        <para>
            To build either a static or shared native library, you define a library component in the <literal>components</literal> container. The following sample
{'fraction_non_alphanumeric': 0.09940667739340306, 'fraction_numerical': 0.0012067578439259854, 'mean_word_length': 2.3175979983319435, 'pattern_counts': {'":': 0, '<': 571, '<?xml version=': 0, '>': 571, 'https://': 0, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, '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': '3517948', 'n_tokens_mistral': 5209, 'n_tokens_neox': 4987, 'n_words': 2016}