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>

5 files changed, 27 insertions, 25 deletions

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index ba182acaf4..ddff77cdc2 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/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
-                    native Multilib support (i.e. support for the host build
-                    machine).
-                    For the RPM Package Management System, the following
-                    implementation details exist:
+                    Different packaging systems have different levels of native Multilib
+                    support.
+                    For the RPM Package Management System, the following 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
-                    cross-recipes (i.e. <filename>nativesdk</filename>
-                    for multiple machines.
+                    reuse the existing native and often cross-recipes 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>
-                            that runs on the host system
+                            However, the host <filename>make check</filename>
                             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.
diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/introduction.xml
index 750d9c681c..57e4a25853 100644
--- a/documentation/ref-manual/introduction.xml
+++ b/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
-                        designed to run on the target machine
-                        (<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>).
+                        choose the installation directory.
                         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
-                       (<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>).
+                       to install the tools.
                        Here is an example:
                        <literallayout class='monospaced'>
      $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml
index 62f792bf7b..6fc39d0b56 100644
--- a/documentation/ref-manual/migration.xml
+++ b/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
-                target machine, and any
-                references need to be updated to use
+                relocatable packages for the native architecture as specified
+                in
+                <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>
diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
index f994a2269d..c4f15c9f9d 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -463,11 +463,10 @@
 
     <para>
         The <filename>chrpath</filename> class
-        is a wrapper around the "chrpath" utility.
-        This utility is used during the build process for
-        <filename>nativesdk</filename>, <filename>cross</filename>, and
-        <filename>cross-canadian</filename> recipes, which run on the host
-        system to create packages for the target hardware and change
+        is a wrapper around the "chrpath" utility, which is used during the
+        build process for <filename>nativesdk</filename>,
+        <filename>cross</filename>, and
+        <filename>cross-canadian</filename> recipes to change
         <filename>RPATH</filename> records within binaries in order to make
         them relocatable.
     </para>
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index b4f6a832ed..e26994503b 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/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