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>

1 files changed, 11 insertions, 11 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.