}

                components.withType(CppComponent) {
                    targetMachines = [machines.windows.architecture('${currentArchitecture}'), machines.linux.architecture('${currentArchitecture}'), machines.macOS.architecture('${currentArchitecture}')]
                }
            }
            project(':deck') {
                dependencies {

====

Target machines - defaults to the build host::
The target machine expresses which machines the application expects to run.
A target machine is identified by its operating system and architecture.
Gradle uses the target machine to decide which tool chain to choose based on availability on the host machine.

The target machine can be configured as follows:

.Configure library target machines

                }
                application {
                    targetMachines = [machines.macOS, machines.linux]
                }
            }
            project(':greeter') {
                apply plugin: 'swift-library'
                library {
                    targetMachines = [machines.macOS, machines.linux]
                }
            }
        """

        settingsFile << """
            rootProject.name = 'app'
        """
        buildFile << """
            apply plugin: 'cpp-application'

            application {
                targetMachines = [machines.host().x86, machines.host().x86_64]
            }
        """
        def headerDir = file('src/main/headers')
        def src1 = file('src/main/cpp/app.cpp').createFile()

====

[[sec:select_swift_target_machines]]
=== Selecting target machines

By default, Gradle will attempt to create a Swift binary variant for the host operating system and architecture.
It is possible to override this by specifying the set of `TargetMachine` on the `application` or `library` script block:

.Setting target machines
====

====

[[sec:select_cpp_target_machines]]
=== Selecting target machines

By default, Gradle will attempt to create a {cpp} binary variant for the host operating system and architecture.
It is possible to override this by specifying the set of `TargetMachine` on the `application` or `library` script block:

.Setting target machines
====

Any variations across machines will result in cache misses.

Never re-release a non-changing binary dependency with the same version number but different contents: if this happens with a plugin dependency, you will never be able to explain why you don’t see cache reuse between machines (it’s because they have different versions of that artifact).

Linux containers run using the same Linux kernel of the host (machine, virtual machine, cloud server, etc). This just means that they are very lightweight (compared to full virtual machines emulating an entire operating system).

This way, containers consume **little resources**, an amount comparable to running the processes directly (a virtual machine would consume much more).

        def releaseBinary = exe("build/exe/main/release/macos/App")

        given:
        buildFile << """
            apply plugin: 'swift-application'

            application.targetMachines = [machines.macOS, machines.linux]
        """

        app.writeToProject(testDirectory)
        //executer.startBuildProcessInDebugger(true)
        succeeds("xcode")

        when:
        debugBinary.assertDoesNotExist()

    /**
     * A Hybrid node tries to resolve a name using the nameserver first. If
     * that fails use the broadcast address. This is the default if a nameserver
     * is provided. This is the behavior of Microsoft Windows machines.
     */

    public static final int H_NODE = 3;

    /**
     * Unknown MAC Address
     */
    public static final byte[] UNKNOWN_MAC_ADDRESS = new byte[] {