ref-manual, dev-manual: Clarifying "native" and "sdknative"

Fixes [YOCTO #8620]

I applied some review comments for the changes made to several
areas in both these manuals.  Minor wording fixes and the
dropping of some changes as directed by Joshua Lock.

(From yocto-docs rev: 71af89da612c37162ba27844c297879d643caf65)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/dev-manual/dev-manual-common-tasks.xml

@@ -3603,11 +3603,10 @@
                 <title>Additional Implementation Details</title>
 
                 <para>
-                    Different packaging systems have different levels of
+                    Different packaging systems have different levels of native Multilib
-                    native Multilib support (i.e. support for the host build
+                    support.
-                    machine).
+                    For the RPM Package Management System, the following implementation details
-                    For the RPM Package Management System, the following
+                    exist:
-                    implementation details exist:
                     <itemizedlist>
                         <listitem><para>A unique architecture is defined for the Multilib packages,
                             along with creating a unique deploy folder under
@@ -6377,9 +6376,8 @@
                     developers when building for multiple machines.
                     When you use the same <filename>TMPDIR</filename> for
                     multiple machine builds, the OpenEmbedded build system can
-                    reuse the existing native (i.e. host system) and often
+                    reuse the existing native and often cross-recipes for
-                    cross-recipes (i.e. <filename>nativesdk</filename>
+                    multiple machines.
-                    for multiple machines.
                     Thus, build time decreases.
                     <note>
                         If
@@ -7582,14 +7580,16 @@
                             Consequently, you usually need to add a
                             cross-compilation function to the package.
                             </para>
+
                             <para>Many packages based on Automake compile and
                             run the test suite by using a single command
                             such as <filename>make check</filename>.
-                            However, the native <filename>make check</filename>
+                            However, the host <filename>make check</filename>
-                            that runs on the host system
                             builds and runs on the same computer, while
                             cross-compiling requires that the package is built
-                            on the host but executed on the target.
+                            on the host but executed for the target
+                            architecture (though often, as in the case for
+                            ptest, the execution occurs on the host).
                             The built version of Automake that ships with the
                             Yocto Project includes a patch that separates
                             building and execution.

documentation/ref-manual/introduction.xml

@@ -450,9 +450,7 @@
      $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
                         </literallayout>
                         During execution, a prompt appears that allows you to
-                        choose the installation directory for these tools
+                        choose the installation directory.
-                        designed to run on the target machine
-                        (<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>).
                         For example, you could choose the following:
                         <literallayout class='monospaced'>
      /home/<replaceable>your-username</replaceable>/buildtools
@@ -532,8 +530,7 @@
                    <listitem><para>
                        On the machine that does not meet the requirements,
                        run the <filename>.sh</filename> file
-                       to install the tools built to run on the target machine
+                       to install the tools.
-                       (<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>).
                        Here is an example:
                        <literallayout class='monospaced'>
      $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh

documentation/ref-manual/migration.xml

@@ -193,9 +193,10 @@
                 as a prefix, which simplifies a lot of the packaging code for
                 <filename>nativesdk</filename> recipes.
                 All custom <filename>nativesdk</filename> recipes, which are
-                recipes built on the host system to create packages for the
+                relocatable packages for the native architecture as specified
-                target machine, and any
+                in
-                references need to be updated to use
+                <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>,
+                and any references need to be updated to use
                 <filename>nativesdk-*</filename> instead of
                 <filename>*-nativesdk</filename>.
             </para>

documentation/ref-manual/ref-classes.xml

@@ -463,11 +463,10 @@
 
     <para>
         The <filename>chrpath</filename> class
-        is a wrapper around the "chrpath" utility.
+        is a wrapper around the "chrpath" utility, which is used during the
-        This utility is used during the build process for
+        build process for <filename>nativesdk</filename>,
-        <filename>nativesdk</filename>, <filename>cross</filename>, and
+        <filename>cross</filename>, and
-        <filename>cross-canadian</filename> recipes, which run on the host
+        <filename>cross-canadian</filename> recipes to change
-        system to create packages for the target hardware and change
         <filename>RPATH</filename> records within binaries in order to make
         them relocatable.
     </para>

documentation/ref-manual/technical-details.xml

@@ -477,7 +477,12 @@
             It does not matter if the work directory changes because it should
             not affect the output for target packages.
             Also, the build process has the objective of making native
-            (build host) or cross packages (target hardware) relocatable.
+            or cross packages relocatable.
+            <note>
+                Both native and cross packages run on the build host.
+                However, cross packages generate output for the target
+                architecture.
+            </note>
             The checksum therefore needs to exclude
             <filename>WORKDIR</filename>.
             The simplistic approach for excluding the work directory is to set