<chapter id='native_software'>
    <title>Building native software</title>

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

    <para>
        The native software 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>

    <para>
        The native software plugins make use of the Gradle <link linkend="software_model">software model</link>.
    </para>

    <section id="sec:native_features">
        <title>Features</title>
        <para>The native software plugins provide:</para>
        <itemizedlist>
            <listitem><para>Support for building native libraries and applications on Windows, Linux, OS X and other platforms.</para></listitem>
            <listitem><para>Support for several source languages.</para></listitem>
            <listitem><para>Support for building different variants of the same software, for different architectures, operating systems, or for any purpose.</para></listitem>
            <listitem><para>Incremental parallel compilation, precompiled headers.</para></listitem>
            <listitem><para>Dependency management between native software components.</para></listitem>
            <listitem><para>Unit test execution.</para></listitem>
            <listitem><para>Generate Visual studio solution and project files.</para></listitem>
            <listitem><para>Deep integration with various tool chain, including discovery of installed tool chains.</para></listitem>
        </itemizedlist>
    </section>

    <section id="sec:supported_languages">
        <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/2012/2013/2015.</td>
            </tr>
            <tr>
                <td>Windows</td><td><ulink url="http://gcc.gnu.org/">GCC</ulink> with <ulink url="http://cygwin.com">Cygwin 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">Cygwin 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 id="sec:tool_chain_installation">
        <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 restriction will be removed in a future Gradle version.
            </para>
        </note>
        <para>To build native software, you will need to have a compatible tool chain installed:
        </para>
        <section id="sec:windows">
            <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 id="sec:os_x">
            <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 id="sec:linux">
            <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 id="sec:native_software_model">
        <title>Native software model</title>
        <para>The native software model builds on the base Gradle <link linkend="software_model_concepts">software model</link>.</para>
        <para>
            To build native software 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 a <firstterm>variant</firstterm>.
            Binary variants are discussed in detail below.
        </para>
    </section>

    <section id="sec:parallel_compilation">
        <title>Parallel Compilation</title>
        <para>
            Gradle uses the single build worker pool to concurrently compile and link native components, by default.
            No special configuration is required to enable concurrent building.
        </para>
        <para>
            By default, the worker pool size is determined by the number of available processors on the build machine (as reported to the build JVM).
            To explicitly set the number of workers use the <literal>--max-workers</literal> command-line option or <literal>org.gradle.workers.max</literal> system property.
            There is generally no need to change this setting from its default.
        </para>
        <para>
            The build worker pool is shared across all build tasks.
            This means that when using <link linkend="sec:parallel_execution">parallel project execution</link>, the maximum number of concurrent individual compilation operations does not increase.
            For example, if the build machine has 4 processing cores and 10 projects are compiling in parallel, Gradle will only use 4 total workers, not 40.
        </para>
    </section>
    <section id="sec:building_a_library">
        <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
            defines a library called <literal>hello</literal>:
        </para>
        <sample id="cppLibraries" dir="native-binaries/c" title="Defining a library component">
            <sourcefile file="build.gradle" snippet="libraries"/>
        </sample>
        <para>
            A library component is represented using <apilink class="org.gradle.nativeplatform.NativeLibrarySpec"/>.
            Each library component can produce at least one shared library binary (<apilink class="org.gradle.nativeplatform.SharedLibraryBinarySpec"/>)
            and at least one static library binary (<apilink class="org.gradle.nativeplatform.StaticLibraryBinarySpec"/>).
        </para>
    </section>
    <section id="sec:building_an_executable">
        <title>Building an executable</title>
        <para>
            To build a native executable, you define an executable component in the <literal>components</literal> container. The following sample defines
            an executable called <literal>main</literal>:
        </para>
        <sample id="cppExecutables" dir="native-binaries/c" title="Defining executable components">
            <sourcefile file="build.gradle" snippet="executables"/>
        </sample>
        <para>
            An executable component is represented using <apilink class="org.gradle.nativeplatform.NativeExecutableSpec"/>. Each executable component can
            produce at least one executable binary (<apilink class="org.gradle.nativeplatform.NativeExecutableBinarySpec"/>).
        </para>
        <para>
            For each component defined, Gradle adds a <apilink class="org.gradle.language.base.FunctionalSourceSet"/> with the same name.
            Each of these functional source sets will contain a language-specific source set for each of the languages supported by the project.
        </para>
    </section>
    <section id="sec:dependents">
        <title>Assembling or building dependents</title>
        <para>
            Sometimes, you may need to <firstterm>assemble</firstterm> (compile and link) or <firstterm>build</firstterm> (compile, link and test) a component or binary and its
            <firstterm>dependents</firstterm> (things that depend upon the component or binary). The native software model provides tasks that enable this capability.
            First, the <firstterm>dependent components</firstterm> report gives insight about the relationships between each component.
            Second, the <firstterm>build and assemble dependents</firstterm> tasks allow you to assemble or build a component and its dependents in one step.
        </para>

        <para>
            In the following example, the build file defines <literal>OpenSSL</literal> as a dependency of <literal>libUtil</literal> and <literal>libUtil</literal> as a dependency of
            <literal>LinuxApp</literal> and <literal>WindowsApp</literal>. Test suites are treated similarly. Dependents can be thought of as reverse dependencies.
            <figure>
                <title>Dependent Components Example</title>
                <imageobject>
                    <imagedata fileref="img/nativeDependents.png"/>
                </imageobject>
            </figure>
            <note>
                By following the dependencies backwards, you can see <literal>LinuxApp</literal> and <literal>WindowsApp</literal> are <firstterm>dependents</firstterm> of <literal>libUtil</literal>.
                When <literal>libUtil</literal> is changed, Gradle will need to recompile or relink <literal>LinuxApp</literal> and <literal>WindowsApp</literal>.
            </note>
        </para>

        <para>
            When you <firstterm>assemble</firstterm> dependents of a component, the component and all of its dependents are compiled and linked, including any test suite binaries. Gradle's
            up-to-date checks are used to only compile or link if something has changed.  For instance, if you have changed source files in a way that do not affect the headers of your project,
            Gradle will be able to skip compilation for dependent components and only need to re-link with the new library.  Tests are not run when assembling a component.
        </para>
        <para>
            When you <firstterm>build</firstterm> dependents of a component, the component and all of its dependent binaries are compiled, linked <emphasis>and checked</emphasis>.
            Checking components means running any <link linkend="sec:check_tasks">check task</link> including executing any test suites, so tests <emphasis>are</emphasis> run when building a component.
        </para>

        <para>
            In the following sections, we will demonstrate the usage of the <userinput>assembleDependents*</userinput>, <userinput>buildDependents*</userinput> and
            <userinput>dependentComponents</userinput> tasks with a sample build that contains a CUnit test suite.
            The build script for the sample is the following:
        </para>
        <sample id="nativeDependentComponentsSample" dir="native-binaries/cunit" title="Sample build" includeLocation="true">
            <sourcefile file="build.gradle" snippet="terse-example"/>
        </sample>

        <section id="sec:dependents_report">

            <title>Dependent components report</title>
            <para>
                Gradle provides a report that you can run from the command-line that shows a graph of components in your project and components that depend upon them.
                The following is an example of running <userinput>gradle dependentComponents</userinput> on the sample project:
            </para>
            <sample id="nativeDependentComponentsReport" dir="native-binaries/cunit" title="Dependent components report">
                <output args="dependentComponents"/>
            </sample>
            <note>
                See <apilink class="org.gradle.api.reporting.dependents.DependentComponentsReport"/> API documentation for more details.
            </note>
            <para>
                By default, non-buildable binaries and test suites are hidden from the report. The <userinput>dependentComponents</userinput> task provides options that allow you
                to see all dependents by using the <literal>--all</literal> option:
            </para>
            <sample id="nativeDependentComponentsReportAll" dir="native-binaries/cunit" title="Dependent components report">
                <output args="dependentComponents --all"/>
            </sample>
            <para>
                Here is the corresponding report for the <literal>operators</literal> component, showing dependents of all its binaries:
            </para>
            <sample id="nativeAssembleDependentComponentsReport" dir="native-binaries/cunit" title="Report of components that depends on the operators component">
                <output args="dependentComponents --component operators"/>
            </sample>
            <para>
                Here is the corresponding report for the <literal>operators</literal> component, showing dependents of all its binaries, including test suites:
            </para>
            <sample id="nativeBuildDependentComponentsReport" dir="native-binaries/cunit" title="Report of components that depends on the operators component, including test suites">
                <output args="dependentComponents --test-suites --component operators"/>
            </sample>
        </section>

        <section id="sec:assemble_dependents">
            <title>Assembling dependents</title>
            <para>
                For each <apilink class="org.gradle.nativeplatform.NativeBinarySpec"/>,
                Gradle will create a task named <userinput>assembleDependents<replaceable>${component.name}${binary.variant}</replaceable></userinput>
                that <firstterm>assembles</firstterm> (compile and link) the binary and all of its dependent binaries.
            </para>
            <para>
                For each <apilink class="org.gradle.nativeplatform.NativeComponentSpec"/>,
                Gradle will create a task named <userinput>assembleDependents<replaceable>${component.name}</replaceable></userinput>
                that <firstterm>assembles</firstterm> all the binaries of the component and all of their dependent binaries.
            </para>
            <para>
                For example, to assemble the dependents of the "passing" flavor of the "static" library binary
                of the "operators" component, you would run the <userinput>assembleDependentsOperatorsPassingStaticLibrary</userinput> task:
            </para>
            <sample id="nativeAssembleDependentComponents" dir="native-binaries/cunit" title="Assemble components that depends on the passing/static binary of the operators component">
                <output args="assembleDependentsOperatorsPassingStaticLibrary"/>
            </sample>
            <para>
                In the output above, the targeted binary gets assembled as well as the test suite binary that depends on it.
            </para>
            <para>
                You can also assemble <emphasis>all</emphasis> of the dependents of a component (i.e. of all its binaries/variants) using the corresponding component task, e.g. <userinput>assembleDependentsOperators</userinput>. This is
                useful if you have many combinations of build types, flavors and platforms and want to assemble all of them.
            </para>
        </section>

        <section id="sec:build_dependents">
            <title>Building dependents</title>
            <para>
                For each <apilink class="org.gradle.nativeplatform.NativeBinarySpec"/>,
                Gradle will create a task named <userinput>buildDependents<replaceable>${component.name}${binary.variant}</replaceable></userinput>
                that <firstterm>builds</firstterm> (compile, link and check) the binary and all of its dependent binaries.
            </para>
            <para>
                For each <apilink class="org.gradle.nativeplatform.NativeComponentSpec"/>,
                Gradle will create a task named <userinput>buildDependents<replaceable>${component.name}</replaceable></userinput>
                that <firstterm>builds</firstterm> all the binaries of the component and all of their dependent binaries.
            </para>
            <para>
                For example, to build the dependents of the "passing" flavor of the "static" library binary
                of the "operators" component, you would run the <userinput>buildDependentsOperatorsPassingStaticLibrary</userinput> task:
            </para>
            <sample id="nativeBuildDependentComponents" dir="native-binaries/cunit" title="Build components that depends on the passing/static binary of the operators component">
                <output args="buildDependentsOperatorsPassingStaticLibrary"/>
            </sample>
            <para>
                In the output above, the targeted binary as well as the test suite binary that depends on it are built and the test suite has run.
            </para>
            <para>
                You can also build <emphasis>all</emphasis> of the dependents of a component (i.e. of all its binaries/variants) using the corresponding component task, e.g. <userinput>buildDependentsOperators</userinput>.
            </para>
        </section>
    </section>

    <section id="sec:native_tasks">
        <title>Tasks</title>
        <para>
            For each <apilink class="org.gradle.nativeplatform.NativeBinarySpec"/> that can be produced by a build,
            a single <firstterm>lifecycle task</firstterm> is constructed that can be used to create that binary, together with a set of other tasks that do the actual
            work of compiling, linking or assembling the binary.
        </para>
        <table>
            <thead>
                <tr>
                    <td>Component Type</td>
                    <td>Native Binary Type</td>
                    <td>Lifecycle task</td>
                    <td>Location of created binary</td>
                </tr>
            </thead>
            <tr>
                <td><apilink class="org.gradle.nativeplatform.NativeExecutableSpec"/></td>
                <td><apilink class="org.gradle.nativeplatform.NativeExecutableBinarySpec"/></td>
                <td><literal><replaceable>${component.name}</replaceable>Executable</literal></td>
                <td><filename><replaceable>${project.buildDir}</replaceable>/exe/<replaceable>${component.name}</replaceable>/<replaceable>${component.name}</replaceable></filename></td>
            </tr>
            <tr>
                <td><apilink class="org.gradle.nativeplatform.NativeLibrarySpec"/></td>
                <td><apilink class="org.gradle.nativeplatform.SharedLibraryBinarySpec"/></td>
                <td><literal><replaceable>${component.name}</replaceable>SharedLibrary</literal></td>
                <td><filename><replaceable>${project.buildDir}</replaceable>/libs/<replaceable>${component.name}</replaceable>/shared/lib<replaceable>${component.name}</replaceable>.so</filename></td>
            </tr>
            <tr>
                <td><apilink class="org.gradle.nativeplatform.NativeLibrarySpec"/></td>
                <td><apilink class="org.gradle.nativeplatform.StaticLibraryBinarySpec"/></td>
                <td><literal><replaceable>${component.name}</replaceable>StaticLibrary</literal></td>
                <td><filename><replaceable>${project.buildDir}</replaceable>/libs/<replaceable>${component.name}</replaceable>/static/<replaceable>${component.name}</replaceable>.a</filename></td>
            </tr>
        </table>

        <section id="sec:check_tasks">
            <title>Check tasks</title>
            <para>
                For each <apilink class="org.gradle.nativeplatform.NativeBinarySpec"/> that can be produced by a build,
                a single <firstterm>check task</firstterm> is constructed that can be used to assemble and check that binary.
            </para>
            <table>
                <thead>
                    <tr>
                        <td>Component Type</td>
                        <td>Native Binary Type</td>
                        <td>Check task</td>
                    </tr>
                </thead>
                <tr>
                    <td><apilink class="org.gradle.nativeplatform.NativeExecutableSpec"/></td>
                    <td><apilink class="org.gradle.nativeplatform.NativeExecutableBinarySpec"/></td>
                    <td><literal>check<replaceable>${component.name}</replaceable>Executable</literal></td>
                </tr>
                <tr>
                    <td><apilink class="org.gradle.nativeplatform.NativeLibrarySpec"/></td>
                    <td><apilink class="org.gradle.nativeplatform.SharedLibraryBinarySpec"/></td>
                    <td><literal>check<replaceable>${component.name}</replaceable>SharedLibrary</literal></td>
                </tr>
                <tr>
                    <td><apilink class="org.gradle.nativeplatform.NativeLibrarySpec"/></td>
                    <td><apilink class="org.gradle.nativeplatform.StaticLibraryBinarySpec"/></td>
                    <td><literal>check<replaceable>${component.name}</replaceable>StaticLibrary</literal></td>
                </tr>
            </table>
            <para>
                The built-in <literal>check</literal> task depends on all the <firstterm>check tasks</firstterm> for binaries in the project.
                Without either <link linkend="native_binaries:cunit">CUnit</link> or <link linkend="native_binaries:google_test">GoogleTest</link> plugins, the binary check task only depends on
                the <firstterm>lifecycle task</firstterm> that assembles the binary, see <xref linkend="sec:native_tasks"/>.
            </para>
            <para>
                When the <link linkend="native_binaries:cunit">CUnit</link> or <link linkend="native_binaries:google_test">GoogleTest</link> plugins are applied, the task that executes the test suites
                for a component are automatically wired to the appropriate <firstterm>check task</firstterm>.
            </para>
            <para>
                You can also add custom check tasks as follows:
            </para>
            <sample id="nativeComponentCustomCheck" dir="native-binaries/custom-check" title="Adding a custom check task" includeLocation="true">
                <sourcefile file="build.gradle" snippet="custom-check"/>
            </sample>
            <para>
                Now, running <literal>check</literal> or any of the <firstterm>check tasks</firstterm> for the <literal>hello</literal> binaries will run the custom check task:
            </para>
            <sample id="nativeComponentCustomCheckOutput" dir="native-binaries/custom-check" title="Running checks for a given binary">
                <output args="checkHelloSharedLibrary"/>
            </sample>
        </section>

        <section id="sec:working_with_shared_libraries">
            <title>Working with shared libraries</title>
            <para>
                For each executable binary produced, the <literal>cpp</literal> plugin provides an <literal>install${binary.name}</literal> task,
                which creates a development install of the executable, along with the shared libraries it requires.
                This allows you to run the executable without needing to install the shared libraries in their final locations.
            </para>
        </section>
    </section>

    <section id="sec:finding_out_more_about_your_project">
        <title>Finding out more about your project</title>
        <para>Gradle provides a report that you can run from the command-line that shows some details about the components and binaries that your
            project produces. To use this report, just run <userinput>gradle components</userinput>. Below is an example of running this report for
            one of the sample projects:
        </para>
        <sample id="nativeComponentReport" dir="native-binaries/cpp" title="The components report">
            <output args='components'/>
        </sample>
    </section>

    <section id="native_binaries:languages">
        <title>Language support</title>
        <para>
            Presently, Gradle supports building native software from any combination of source languages listed below.
            A native binary project will contain one or more named <literal>FunctionalSourceSet</literal> instances (eg 'main', 'test', etc),
            each of which can contain <literal>LanguageSourceSet</literal>s containing source files, one for each language.
        </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 id="sec:cpp_sources">
            <title>C++ sources</title>
            <para>
                C++ language support is provided by means of the <literal>'cpp'</literal> plugin.
            </para>
            <sample id="cppPlugin" dir="native-binaries/cpp" title="The 'cpp' plugin">
                <sourcefile file="build.gradle" snippet="apply-plugin"/>
            </sample>
            <para>
                C++ sources to be included in a native binary are provided via a <apilink class="org.gradle.language.cpp.CppSourceSet"/>,
                which defines a set of C++ source files and optionally a set of exported header files (for a library).
                By default, for any named component the <apilink class="org.gradle.language.cpp.CppSourceSet"/> contains
                <filename>.cpp</filename> source files in <filename>src/${name}/cpp</filename>,
                and header files in <filename>src/${name}/headers</filename>.
            </para>
            <para>
                While the <literal>cpp</literal> plugin defines these default locations for each <apilink class="org.gradle.language.cpp.CppSourceSet"/>,
                it is possible to extend or override these defaults to allow for a different project layout.
            </para>
            <sample id="cppSourceSet" dir="native-binaries/custom-layout" title="C++ source set">
                <sourcefile file="build.gradle" snippet="cpp-sources"/>
            </sample>
            <para>
                For a library named 'main', header files in <filename>src/main/headers</filename> are considered the “public” or “exported” headers.
                Header files that should not be exported should be placed inside the <filename>src/main/cpp</filename> directory (though be aware that
                such header files should always be referenced in a manner relative to the file including them).
            </para>
        </section>

        <section id="sec:c_sources">
            <title>C sources</title>
            <para>
                C language support is provided by means of the <literal>'c'</literal> plugin.
            </para>
            <sample id="cPlugin" dir="native-binaries/c" title="The 'c' plugin">
                <sourcefile file="build.gradle" snippet="apply-plugin"/>
            </sample>
            <para>
                C sources to be included in a native binary are provided via a <apilink class="org.gradle.language.c.CSourceSet"/>,
                which defines a set of C source files and optionally a set of exported header files (for a library).
                By default, for any named component the <apilink class="org.gradle.language.c.CSourceSet"/> contains
                <filename>.c</filename> source files in <filename>src/${name}/c</filename>,
                and header files in <filename>src/${name}/headers</filename>.
            </para>
            <para>
                While the <literal>c</literal> plugin defines these default locations for each <apilink class="org.gradle.language.c.CSourceSet"/>,
                it is possible to extend or override these defaults to allow for a different project layout.
            </para>
            <sample id="cSourceSet" dir="native-binaries/custom-layout" title="C source set">
                <sourcefile file="build.gradle" snippet="c-sources"/>
            </sample>
            <para>
                For a library named 'main', header files in <filename>src/main/headers</filename> are considered the “public” or “exported” headers.
                Header files that should not be exported should be placed inside the <filename>src/main/c</filename> directory (though be aware that
                such header files should always be referenced in a manner relative to the file including them).
            </para>
        </section>

        <section id="sec:assembler_sources">
            <title>Assembler sources</title>
            <para>
                Assembly language support is provided by means of the <literal>'assembler'</literal> plugin.
            </para>
            <sample id="assemblerPlugin" dir="native-binaries/assembler" title="The 'assembler' plugin">
                <sourcefile file="build.gradle" snippet="apply-plugin"/>
            </sample>
            <para>
                Assembler sources to be included in a native binary are provided via a <apilink class="org.gradle.language.assembler.AssemblerSourceSet"/>,
                which defines a set of Assembler source files.
                By default, for any named component the <apilink class="org.gradle.language.assembler.AssemblerSourceSet"/> contains
                <filename>.s</filename> source files under <filename>src/${name}/asm</filename>.
            </para>
        </section>

        <section id="sec:objectivec_sources">
            <title>Objective-C sources</title>
            <para>
                Objective-C language support is provided by means of the <literal>'objective-c'</literal> plugin.
            </para>
            <sample id="objectiveCPlugin" dir="native-binaries/objective-c" title="The 'objective-c' plugin">
                <sourcefile file="build.gradle" snippet="apply-plugin"/>
            </sample>
            <para>
                Objective-C sources to be included in a native binary are provided via a <apilink class="org.gradle.language.objectivec.ObjectiveCSourceSet"/>,
                which defines a set of Objective-C source files.
                By default, for any named component the <apilink class="org.gradle.language.objectivec.ObjectiveCSourceSet"/> contains
                <filename>.m</filename> source files under <filename>src/${name}/objectiveC</filename>.
            </para>
        </section>

        <section id="sec:objectivecpp_sources">
            <title>Objective-C++ sources</title>
            <para>
                Objective-C++ language support is provided by means of the <literal>'objective-cpp'</literal> plugin.
            </para>
            <sample id="objectiveCppPlugin" dir="native-binaries/objective-cpp" title="The 'objective-cpp' plugin">
                <sourcefile file="build.gradle" snippet="apply-plugin"/>
            </sample>
            <para>
                Objective-C++ sources to be included in a native binary are provided via a <apilink class="org.gradle.language.objectivecpp.ObjectiveCppSourceSet"/>,
                which defines a set of Objective-C++ source files.
                By default, for any named component the <apilink class="org.gradle.language.objectivecpp.ObjectiveCppSourceSet"/> contains
                <filename>.mm</filename> source files under <filename>src/${name}/objectiveCpp</filename>.
            </para>
        </section>
    </section>

    <section id="sec:configuring_the_compiler_assembler_and_linker">
        <title>Configuring the compiler, assembler and linker</title>
        <para>
            Each binary to be produced is associated with a set of compiler and linker settings, which include command-line arguments as well as macro definitions.
            These settings can be applied to all binaries, an individual binary, or selectively to a group of binaries based on some criteria.
        </para>
        <sample id="allBinarySettings" dir="native-binaries/cpp" title="Settings that apply to all binaries">
            <sourcefile file="build.gradle" snippet="all-binaries"/>
        </sample>
        <para>
            Each binary is associated with a particular <apilink class="org.gradle.nativeplatform.toolchain.NativeToolChain"/>, allowing settings to be targeted based on
            this value.
        </para>
        <para>
            It is easy to apply settings to all binaries of a particular type:
        </para>
        <sample id="allSharedLibraryBinarySettings" dir="native-binaries/c" title="Settings that apply to all shared libraries">
            <sourcefile file="build.gradle" snippet="all-shared-libraries"/>
        </sample>
        <para>
            Furthermore, it is possible to specify settings that apply to all binaries produced for a particular <literal>executable</literal>
            or <literal>library</literal> component:
        </para>
        <sample id="componentBinarySettings" dir="native-binaries/assembler" title="Settings that apply to all binaries produced for the 'main' executable component">
            <sourcefile file="build.gradle" snippet="assembler-args"/>
        </sample>
        <para>
            The example above will apply the supplied configuration to all <literal>executable</literal> binaries built.
        </para>
        <para>
            Similarly, settings can be specified to target binaries for a component that are of a particular type:
            eg all shared libraries for the main library component.
        </para>
        <sample id="sharedLibraryArgs" dir="native-binaries/cpp-lib" title="Settings that apply only to shared libraries produced for the 'main' library component">
            <sourcefile file="build.gradle" snippet="args"/>
        </sample>
    </section>

    <section id="native_binaries:windows-resources">
        <title>Windows Resources</title>
        <para>
            When using the <apilink class="org.gradle.nativeplatform.toolchain.VisualCpp"/> tool chain, Gradle is able to compile Window Resource (<literal>rc</literal>)
            files and link them into a native binary. This functionality is provided by the <literal>'windows-resources'</literal> plugin.
        </para>
        <sample id="windowsResourcesPlugin" dir="native-binaries/windows-resources" title="The 'windows-resources' plugin">
            <sourcefile file="build.gradle" snippet="apply-plugin"/>
        </sample>
        <para>
            Windows resources to be included in a native binary are provided via a <apilink class="org.gradle.language.rc.WindowsResourceSet"/>,
            which defines a set of Windows Resource source files.
            By default, for any named component the <apilink class="org.gradle.language.rc.WindowsResourceSet"/> contains
            <filename>.rc</filename> source files under <filename>src/${name}/rc</filename>.
        </para>
        <para>
            As with other source types, you can configure the location of the windows resources that should be included in the binary.
        </para>
        <sample id="windowsResourceSet" dir="native-binaries/windows-resources" title="Configuring the location of Windows resource sources">
            <sourcefile file="build-resource-only-dll.gradle" snippet="windows-resource-set"/>
        </sample>
        <para>
            You are able to construct a resource-only library by providing Windows Resource sources with no other language sources,
            and configure the linker as appropriate:
        </para>
        <sample id="resourceOnlyDll" dir="native-binaries/windows-resources" title="Building a resource-only dll">
            <sourcefile file="build-resource-only-dll.gradle" snippet="resource-only-library"/>
        </sample>
        <para>
            The example above also demonstrates the mechanism of passing extra command-line arguments to the resource compiler.
            The <literal>rcCompiler</literal> extension is of type <apilink class="org.gradle.nativeplatform.PreprocessingTool"/>.
        </para>
    </section>

    <section id="sec:library_dependencies">
        <title>Library Dependencies</title>
        <para>
            Dependencies for native components are binary libraries that export header files. The header files are used during compilation, with the compiled
            binary dependency being used during linking and execution. Header files should be organized into subdirectories to prevent clashes of commonly named headers.
            For instance, if your <literal>mylib</literal> project has a <filename>logging.h</filename> header, it will make it less likely the wrong header is used if you include it as
            <literal>"mylib/logging.h"</literal> instead of <literal>"logging.h"</literal>.
        </para>
        <section id="sec:dependencies_within_the_same_project">
           <title>Dependencies within the same project</title>
           <para>
               A set of sources may depend on header files provided by another binary component within the same project.
               A common example is a native executable component that uses functions provided by a separate native library component.
           </para>
           <para>
               Such a library dependency can be added to a source set associated with the <literal>executable</literal> component:
           </para>
           <sample id="cppSourceLibrary" dir="native-binaries/cpp" title="Providing a library dependency to the source set">
               <sourcefile file="build.gradle" snippet="source-library"/>
           </sample>
           <para>
               Alternatively, a library dependency can be provided directly to the <literal>NativeExecutableBinarySpec</literal> for the <literal>executable</literal>.
           </para>
           <sample id="cppBinaryLibrary" dir="native-binaries/custom-layout" title="Providing a library dependency to the binary">
               <sourcefile file="build.gradle" snippet="binary-library"/>
           </sample>
        </section>
        <section id="sec:project_dependencies">
            <title>Project Dependencies</title>
            <para>
                For a component produced in a different Gradle project, the notation is similar.
            </para>
            <sample id="cppProjectDependencies" dir="native-binaries/multi-project" title="Declaring project dependencies">
                <sourcefile file="build.gradle" snippet="project-dependencies"/>
            </sample>
        </section>
    </section>

    <section id="native_binaries:preCompiledHeaders">
        <title>Precompiled Headers</title>
        <para>
            Precompiled headers are a performance optimization that reduces the cost of compiling widely used headers multiple times.
            This feature <firstterm>precompiles</firstterm> a header such that the compiled object file can be reused when
            compiling each source file rather than recompiling the header each time.  This support is available for C, C++, Objective-C,
            and Objective-C++ builds.
        </para>
        <para>
            To configure a precompiled header, first a header file needs to be defined that includes all of the headers that should
            be precompiled.  It must be specified as the first included header in every source file where the precompiled header
            should be used.  It is assumed that this header file, and any headers it contains, make use of header guards so that they can be included
            in an idempotent manner.  If header guards are not used in a header file, it is possible the header could be compiled more
            than once and could potentially lead to a broken build.
        </para>
        <sample id="preCompiledHeaderFile" dir="native-binaries/pre-compiled-headers" title="Creating a precompiled header file">
            <sourcefile file="src/hello/headers/pch.h" />
        </sample>
        <sample id="preCompiledHeaderFile" dir="native-binaries/pre-compiled-headers" title="Including a precompiled header file in a source file">
            <sourcefile file="src/hello/cpp/hello.cpp" />
        </sample>
        <para>
            Precompiled headers are specified on a source set.  Only one precompiled header file can be specified on a given source set and will
            be applied to all source files that declare it as the first include.  If a source files does not include this header file as the
            first header, the file will be compiled in the normal manner (without making use of the precompiled header object file).  The string provided
            should be the same as that which is used in the "#include" directive in the source files.
        </para>
        <sample id="preCompiledHeaderConfig" dir="native-binaries/pre-compiled-headers" title="Configuring a precompiled header">
            <sourcefile file="build.gradle" snippet="libraries"/>
        </sample>
        <para>
            A precompiled header must be included in the same way for all files that use it.  Usually, this means the header file should exist
            in the source set "headers" directory or in a directory included on the compiler include path.
        </para>
    </section>

    <section id="native_binaries:variants">
        <title>Native Binary Variants</title>
        <para>
            For each executable or library defined, Gradle is able to build a number of different native binary variants.
            Examples of different variants include debug vs release binaries, 32-bit vs 64-bit binaries, and binaries produced
            with different custom preprocessor flags.
        </para>
        <para>
            Binaries produced by Gradle can be differentiated on
                <link linkend="native_binaries:build_type">build type</link>,
                <link linkend="native_binaries:platform">platform</link>, and
                <link linkend="native_binaries:flavor">flavor</link>.
            For each of these 'variant dimensions', it is possible to specify a set of available values as well as target each component at
            one, some or all of these. For example, a plugin may define a range of support platforms, but you
            may choose to only target Windows-x86 for a particular component.
        </para>

        <section id="native_binaries:build_type">
            <title>Build types</title>
            <para>
                A <literal>build type</literal> determines various non-functional aspects of a binary, such as whether debug information is included,
                or what optimisation level the binary is compiled with. Typical build types are 'debug' and 'release', but a project
                is free to define any set of build types.
            </para>
            <sample id="buildTypes" dir="native-binaries/variants" title="Defining build types">
                <sourcefile file="build.gradle" snippet="build-types"/>
            </sample>
            <para>
                If no build types are defined in a project, then a single, default build type called 'debug' is added.
            </para>
            <para>
                For a build type, a Gradle project will typically define a set of compiler/linker flags per tool chain.
            </para>
            <sample id="buildTypeConfig" dir="native-binaries/variants" title="Configuring debug binaries">
                <sourcefile file="build.gradle" snippet="build-type-config"/>
            </sample>
            <note>
                At this stage, it is completely up to the build script to configure the relevant compiler/linker flags for each
                build type. Future versions of Gradle will automatically include the appropriate debug flags for any 'debug' build
                type, and may be aware of various levels of optimisation as well.
            </note>
        </section>

        <section id="native_binaries:platform">
            <title>Platform</title>
            <para>
                An executable or library can be built to run on different operating systems and cpu architectures, with a variant being
                produced for each platform. Gradle defines each OS/architecture combination as a <apilink class="org.gradle.nativeplatform.platform.NativePlatform"/>,
                and a project may define any number of platforms.
                If no platforms are defined in a project, then a single, default platform 'current' is added.
            </para>
            <note>
                Presently, a <literal>Platform</literal> consists of a defined operating system and architecture. As we continue to develop the
                native binary support in Gradle, the concept of Platform will be extended to include things like C-runtime version, Windows SDK, ABI, etc.
                Sophisticated builds may use the extensibility of Gradle to apply additional attributes to each platform, which can then be queried to
                specify particular includes, preprocessor macros or compiler arguments for a native binary.
            </note>
            <sample id="platforms" dir="native-binaries/variants" title="Defining platforms">
                <sourcefile file="build.gradle" snippet="platforms"/>
            </sample>
            <para>
                For a given variant, Gradle will attempt to find a <apilink class="org.gradle.nativeplatform.toolchain.NativeToolChain"/> that is able to build
                for the target platform. Available tool chains are searched in the order defined.
                See the <link linkend="native_binaries:tool_chain">tool chains</link> section below for more details.
            </para>
        </section>

        <section id="native_binaries:flavor">
            <title>Flavor</title>
            <para>
                Each component can have a set of named <literal>flavors</literal>, and a separate binary variant can be produced for each flavor.
                While the <literal>build type</literal> and <literal>target platform</literal> variant dimensions have a defined meaning in Gradle,
                each project is free to define any number of flavors and apply meaning to them in any way.
            </para>
            <para>
                An example of component flavors might differentiate between 'demo', 'paid' and 'enterprise' editions of the component,
                where the same set of sources is used to produce binaries with different functions.
            </para>
            <sample id="flavors" dir="native-binaries/flavors" title="Defining flavors">
                <sourcefile file="build.gradle" snippet="flavors"/>
            </sample>
            <para>
                In the example above, a library is defined with a 'english' and 'french' flavor. When compiling the 'french'
                variant, a separate macro is defined which leads to a different binary being produced.
            </para>
            <para>
                If no flavor is defined for a component, then a single default flavor named 'default' is used.
            </para>
        </section>
        <section id="sec:selecting_the_build_types_platforms_and_flavors_for_a_component">
            <title>Selecting the build types, platforms and flavors for a component</title>
            <para>
                For a default component, Gradle will attempt to create a native binary variant for each and every combination of <literal>buildType</literal>
                and <literal>flavor</literal> defined for the project. It is possible to override this on a per-component
                basis, by specifying the set of <literal>targetBuildTypes</literal> and/or <literal>targetFlavors</literal>.
                By default, Gradle will build for the default platform, see <link linkend="native_binaries:platform">above</link>,
                unless specified explicitly on a per-component basis by specifying a set of <literal>targetPlatforms</literal>.
            </para>
            <sample id="targets" dir="native-binaries/variants" title="Targeting a component at particular platforms">
                <sourcefile file="build.gradle" snippet="target-platforms"/>
            </sample>
            <para>
                Here you can see that the <apilink class="org.gradle.nativeplatform.TargetedNativeComponent" method="targetPlatform"/> method is used to
                specify a platform that the <literal>NativeExecutableSpec</literal> named <literal>main</literal> should be built for.
            </para>
            <para>
                A similar mechanism exists for selecting <apilink class="org.gradle.nativeplatform.TargetedNativeComponent" method="targetBuildTypes"/>
                and <apilink class="org.gradle.nativeplatform.TargetedNativeComponent" method="targetFlavors"/>.
            </para>
        </section>
        <section id="sec:building_all_possible_variants">
            <title>Building all possible variants</title>
            <para>
                When a set of build types, target platforms, and flavors is defined for a component,
                a <apilink class="org.gradle.nativeplatform.NativeBinarySpec"/> model element is created for every possible
                combination of these. However, in many cases it is not possible to build a particular variant, perhaps because
                no tool chain is available to build for a particular platform.
            </para>
            <para>
                If a binary variant cannot be built for any reason, then the <apilink class="org.gradle.nativeplatform.NativeBinarySpec"/>
                associated with that variant will not be <literal>buildable</literal>. It is possible to use this property to create a task
                to generate all possible variants on a particular machine.
            </para>
            <sample id="buildable" dir="native-binaries/tool-chains" title="Building all possible variants">
                <sourcefile file="build.gradle" snippet="buildable"/>
            </sample>
        </section>
    </section>

    <section id="native_binaries:tool_chain">
        <title>Tool chains</title>
        <para>
            A single build may utilize different tool chains to build variants for different platforms. To this end,
            the core 'native-binary' plugins will attempt to locate and make available supported tool chains. However, the set
            of tool chains for a project may also be explicitly defined, allowing additional cross-compilers to be configured
            as well as allowing the install directories to be specified.
        </para>
        <section id="sec:defining_tool_chains">
            <title>Defining tool chains</title>
            <para>
                The supported tool chain types are:
            </para>
            <itemizedlist>
                <listitem>
                    <para><apilink class="org.gradle.nativeplatform.toolchain.Gcc"/></para>
                </listitem>
                <listitem>
                    <para><apilink class="org.gradle.nativeplatform.toolchain.Clang"/></para>
                </listitem>
                <listitem>
                    <para><apilink class="org.gradle.nativeplatform.toolchain.VisualCpp"/></para>
                </listitem>
            </itemizedlist>
            <sample id="toolChains" dir="native-binaries/tool-chains" title="Defining tool chains">
                <sourcefile file="build.gradle" snippet="toolChains"/>
            </sample>
            <para>
                Each tool chain implementation allows for a certain degree of configuration (see the API documentation for more details).
            </para>

        </section>

        <section id="sec:using_tool_chains">
            <title>Using tool chains</title>
            <para>
                It is not necessary or possible to specify the tool chain that should be used to build.
                For a given variant, Gradle will attempt to locate a <apilink class="org.gradle.nativeplatform.toolchain.NativeToolChain"/> that is able to build
                for the target platform. Available tool chains are searched in the order defined.
            </para>
            <note>
                When a platform does not define an architecture or operating system, the default target of the tool chain
                is assumed. So if a platform does not define a value for <literal>operatingSystem</literal>,
                Gradle will find the first available tool chain that can build for the specified <literal>architecture</literal>.
            </note>
            <para>
                The core Gradle tool chains are able to target the following architectures out of the box. In each case, the tool chain
                will target the current operating system. See the next section for information on cross-compiling for other operating systems.
            </para>
            <table>
                <thead>
                    <tr><td>Tool Chain</td><td>Architectures</td></tr>
                </thead>
                <tr>
                    <td>GCC</td><td>x86, x86_64</td>
                </tr>
                <tr>
                    <td>Clang</td><td>x86, x86_64</td>
                </tr>
                <tr>
                    <td>Visual C++</td><td>x86, x86_64, ia-64</td>
                </tr>
            </table>
            <para>
                So for GCC running on linux, the supported target platforms are 'linux/x86' and 'linux/x86_64'.
                For GCC running on Windows via Cygwin, platforms 'windows/x86' and 'windows/x86_64' are supported.
                (The Cygwin POSIX runtime is not yet modelled as part of the platform, but will be in the future.)
            </para>
            <para>
                If no target platforms are defined for a project, then all binaries are built to target a default platform named 'current'.
                This default platform does not specify any <literal>architecture</literal> or <literal>operatingSystem</literal> value,
                hence using the default values of the first available tool chain.
            </para>
            <para>
                Gradle provides a <firstterm>hook</firstterm> that allows the build author to control the exact set of arguments passed to a tool chain executable.
                This enables the build author to work around any limitations in Gradle, or assumptions that Gradle makes.
                The arguments hook should be seen as a 'last-resort' mechanism, with preference given to truly modelling the underlying domain.
            </para>
            <sample id="withArguments" dir="native-binaries/tool-chains" title="Reconfigure tool arguments">
                <sourcefile file="build.gradle" snippet="withArguments"/>
            </sample>
        </section>

        <section id="sec:crosscompiling_with_gcc">
            <title>Cross-compiling with GCC</title>
            <para>
                Cross-compiling is possible with the <apilink class="org.gradle.nativeplatform.toolchain.Gcc"/> and <apilink class="org.gradle.nativeplatform.toolchain.Clang"/> tool chains,
                by adding support for additional target platforms.
                This is done by specifying a target platform for a toolchain. For each target platform a custom configuration can be specified.
            </para>
            <sample id="targetPlatforms" dir="native-binaries/target-platforms" title="Defining target platforms">
                <sourcefile file="build.gradle" snippet="targetplatforms"/>
            </sample>
        </section>
    </section>
    <section id="native_binaries:visual_studio">
        <title>Visual Studio IDE integration</title>
        <para>
            Gradle has the ability to generate Visual Studio project and solution files for the native components defined in your build.
            This ability is added by the <literal>visual-studio</literal> plugin. For a multi-project build, all projects with native components
            should have this plugin applied.
        </para>
        <para>
            When the <literal>visual-studio</literal> plugin is applied, a task name <literal>${component.name}VisualStudio</literal> is created
            for each defined component. This task will generate a Visual Studio Solution file for the named component. This solution will include
            a Visual Studio Project for that component, as well as linking to project files for each depended-on binary.
        </para>
        <para>
            The content of the generated visual studio files can be modified via API hooks, provided by the <literal>visualStudio</literal>
            extension. Take a look at the 'visual-studio' sample, or see <apilink class="org.gradle.ide.visualstudio.VisualStudioExtension" method="getProjects"/>
            and <apilink class="org.gradle.ide.visualstudio.VisualStudioExtension" method="getSolutions"/> in the API documentation for more details.
        </para>
    </section>
    <section id="native_binaries:cunit">
        <title>CUnit support</title>
        <para>
            The Gradle <literal>cunit</literal> plugin provides support for compiling and executing CUnit tests in your native-binary project.
            For each <apilink class="org.gradle.nativeplatform.NativeExecutableSpec"/> and <apilink class="org.gradle.nativeplatform.NativeLibrarySpec"/>
            defined in your project, Gradle will create a matching <apilink class="org.gradle.nativeplatform.test.cunit.CUnitTestSuiteSpec"/> component,
            named <literal>${component.name}Test</literal>.
        </para>
        <section id="sec:cunit_sources">
            <title>CUnit sources</title>
            <para>
                Gradle will create a <apilink class="org.gradle.language.c.CSourceSet"/> named 'cunit' for each <apilink class="org.gradle.nativeplatform.test.cunit.CUnitTestSuiteSpec"/> component
                in the project. This source set should contain the cunit test files for the component under test. Source files can be located in the conventional location
                (<literal>src/${component.name}Test/cunit</literal>) or can be configured like any other source set.
            </para>
            <para>
                Gradle initialises the CUnit test registry and executes the tests, utilising some generated CUnit launcher sources.
                Gradle will expect and call a function with the signature <literal>void gradle_cunit_register()</literal> that you can use to configure the
                actual CUnit suites and tests to execute.
            </para>
            <sample id="cunitSources" dir="native-binaries/cunit/src/operatorsTest/c" title="Registering CUnit tests">
                <sourcefile file="suite_operators.c"/>
            </sample>
            <note>
                Due to this mechanism, your CUnit sources may not contain a <literal>main</literal> method since this will clash with the method provided by Gradle.
            </note>
        </section>

        <section id="sec:building_cunit_executables">
            <title>Building CUnit executables</title>
            <para>
                A <apilink class="org.gradle.nativeplatform.test.cunit.CUnitTestSuiteSpec"/> component has an associated
                <apilink class="org.gradle.nativeplatform.NativeExecutableSpec"/> or <apilink class="org.gradle.nativeplatform.NativeLibrarySpec"/> component.
                For each <apilink class="org.gradle.nativeplatform.NativeBinarySpec"/> configured for the main component, a matching
                <apilink class="org.gradle.nativeplatform.test.cunit.CUnitTestSuiteBinarySpec"/> will be configured on the test suite component.
                These test suite binaries can be configured in a similar way to any other binary instance:
            </para>
            <sample id="cunitSources" dir="native-binaries/cunit" title="Registering CUnit tests">
                <sourcefile file="build.gradle" snippet="configure-test-binary"/>
            </sample>
            <note>
                Both the CUnit sources provided by your project and the generated launcher require the core CUnit headers and libraries.
                Presently, this library dependency must be provided by your project for each <apilink class="org.gradle.nativeplatform.test.cunit.CUnitTestSuiteBinarySpec"/>.
            </note>
        </section>

        <section id="sec:running_cunit_tests">
            <title>Running CUnit tests</title>
            <para>
                For each <apilink class="org.gradle.nativeplatform.test.cunit.CUnitTestSuiteBinarySpec"/>, Gradle will create a task to execute this binary,
                which will run all of the registered CUnit tests.
                Test results will be found in the <literal><replaceable>${build.dir}</replaceable>/test-results</literal> directory.
            </para>
            <sample id="completeCUnitExample" dir="native-binaries/cunit" title="Running CUnit tests" includeLocation="true">
                <sourcefile file="build.gradle" snippet="complete-example"/>
                <output args='-q runOperatorsTestFailingCUnitExe' expectFailure="true"/>
            </sample>
        </section>

        <note>
            <para>
                The current support for CUnit is quite rudimentary. Plans for future integration include:
            </para>
            <itemizedlist>
                <listitem>
                    <para>Allow tests to be declared with Javadoc-style annotations.</para>
                </listitem>
                <listitem>
                    <para>Improved HTML reporting, similar to that available for JUnit.</para>
                </listitem>
                <listitem>
                    <para>Real-time feedback for test execution.</para>
                </listitem>
                <listitem>
                    <para>Support for additional test frameworks.</para>
                </listitem>
            </itemizedlist>
        </note>
    </section>
    <section id="native_binaries:google_test">
        <title>GoogleTest support</title>
        <para>
            The Gradle <literal>google-test</literal> plugin provides support for compiling and executing GoogleTest tests in your native-binary project.
            For each <apilink class="org.gradle.nativeplatform.NativeExecutableSpec"/> and <apilink class="org.gradle.nativeplatform.NativeLibrarySpec"/>
            defined in your project, Gradle will create a matching <apilink class="org.gradle.nativeplatform.test.googletest.GoogleTestTestSuiteSpec"/> component,
            named <literal>${component.name}Test</literal>.
        </para>
        <section id="sec:googletest_sources">
            <title>GoogleTest sources</title>
            <para>
                Gradle will create a <apilink class="org.gradle.language.cpp.CppSourceSet"/> named 'cpp' for each <apilink class="org.gradle.nativeplatform.test.googletest.GoogleTestTestSuiteSpec"/> component
                in the project. This source set should contain the GoogleTest test files for the component under test. Source files can be located in the conventional location
                (<literal>src/${component.name}Test/cpp</literal>) or can be configured like any other source set.
            </para>
        </section>

        <section id="sec:building_googletest_executables">
            <title>Building GoogleTest executables</title>
            <para>
                A <apilink class="org.gradle.nativeplatform.test.googletest.GoogleTestTestSuiteSpec"/> component has an associated
                <apilink class="org.gradle.nativeplatform.NativeExecutableSpec"/> or <apilink class="org.gradle.nativeplatform.NativeLibrarySpec"/> component.
                For each <apilink class="org.gradle.nativeplatform.NativeBinarySpec"/> configured for the main component, a matching
                <apilink class="org.gradle.nativeplatform.test.googletest.GoogleTestTestSuiteBinarySpec"/> will be configured on the test suite component.
                These test suite binaries can be configured in a similar way to any other binary instance:
            </para>
            <sample id="googleTestSources" dir="native-binaries/google-test" title="Registering GoogleTest tests" includeLocation="true">
                <sourcefile file="build.gradle" snippet="configure-test-binary"/>
            </sample>
            <note>
                The GoogleTest sources provided by your project require the core GoogleTest headers and libraries.
                Presently, this library dependency must be provided by your project for each <apilink class="org.gradle.nativeplatform.test.googletest.GoogleTestTestSuiteBinarySpec"/>.
            </note>
        </section>

        <section id="sec:running_googletest_tests">
            <title>Running GoogleTest tests</title>
            <para>
                For each <apilink class="org.gradle.nativeplatform.test.googletest.GoogleTestTestSuiteBinarySpec"/>, Gradle will create a task to execute this binary,
                which will run all of the registered GoogleTest tests.
                Test results will be found in the <literal><replaceable>${build.dir}</replaceable>/test-results</literal> directory.
            </para>
            <!-- Google test sample output is nondeterministic -->
            <!--<sample id="completeGoogleTestExample" dir="native-binaries/google-test" title="Running GoogleTest tests" includeLocation="true">-->
                <!--<sourcefile file="build.gradle" snippet="complete-example"/>-->
                <!--<output args='-q runFailingOperatorsTestGoogleTestExe' expectFailure="true"/>-->
            <!--</sample>-->
        </section>

        <note>
            <para>
                The current support for GoogleTest is quite rudimentary. Plans for future integration include:
            </para>
            <itemizedlist>
                <listitem>
                    <para>Improved HTML reporting, similar to that available for JUnit.</para>
                </listitem>
                <listitem>
                    <para>Real-time feedback for test execution.</para>
                </listitem>
                <listitem>
                    <para>Support for additional test frameworks.</para>
                </listitem>
            </itemizedlist>
        </note>
    </section>
</chapter>
