From c5b4f69821c7b5ef9047c41198535eb900ea7b94 Mon Sep 17 00:00:00 2001
From: Scott Rifenbark <srifenbark@gmail.com>
Date: Tue, 16 Feb 2016 15:42:55 -0800
Subject: ref-manual, dev-manual: Clarification of "native" and "sdknative"

Fixes [YOCTO #8620]

I went through and made some judgement calls on the use of
"native" and "sdknative".  I tried to make sure that the reader
understood the real meaning of these terms.

(From yocto-docs rev: d711e8c6dfb32a4ad79e9d11dbf44fbc759d0245)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 .../dev-manual/dev-manual-common-tasks.xml          | 21 +++++++++++++--------
 documentation/dev-manual/dev-manual-start.xml       | 19 +++++++++++--------
 2 files changed, 24 insertions(+), 16 deletions(-)

(limited to 'documentation/dev-manual')

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index e0db037454..ba182acaf4 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -3603,10 +3603,11 @@
                 <title>Additional Implementation Details</title>
 
                 <para>
-                    Different packaging systems have different levels of native Multilib
-                    support.
-                    For the RPM Package Management System, the following implementation details
-                    exist:
+                    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:
                     <itemizedlist>
                         <listitem><para>A unique architecture is defined for the Multilib packages,
                             along with creating a unique deploy folder under
@@ -3823,7 +3824,8 @@
                         in the form generated by the build system.
                         </para></listitem>
                     <listitem><para>
-                        You must build several native tools:
+                        You must build several native tools, which are tools
+                        built to run on the build system:
                         <literallayout class='monospaced'>
      $ bitbake parted-native dosfstools-native mtools-native
                         </literallayout>
@@ -6375,8 +6377,9 @@
                     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 and often cross-recipes for
-                    multiple machines.
+                    reuse the existing native (i.e. host system) and often
+                    cross-recipes (i.e. <filename>nativesdk</filename>
+                    for multiple machines.
                     Thus, build time decreases.
                     <note>
                         If
@@ -7583,6 +7586,7 @@
                             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
                             builds and runs on the same computer, while
                             cross-compiling requires that the package is built
                             on the host but executed on the target.
@@ -8169,7 +8173,8 @@
                         specific to or dependent on the target
                         architecture:</emphasis>
                         You can work around these attempts by using native
-                        tools to accomplish the same tasks, or
+                        tools, which run on the host system,
+                        to accomplish the same tasks, or
                         by alternatively running the processes under QEMU,
                         which has the <filename>qemu_run_binary</filename>
                         function.
diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml
index db989b7bfa..9f349adcdd 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -341,14 +341,17 @@
     </para>
 
     <para>
-        Using a pre-built binary is ideal for developing software applications to run on your
-        target hardware.
-        To do this, you need to be able to access the appropriate cross-toolchain tarball for
-        the architecture on which you are developing.
-        If you are using an SDK type image, the image ships with the complete toolchain native to
-        the architecture.
-        If you are not using an SDK type image, you need to separately download and
-        install the stand-alone Yocto Project cross-toolchain tarball.
+        Using a pre-built binary is ideal for developing software
+        applications to run on your target hardware.
+        To do this, you need to be able to access the appropriate
+        cross-toolchain tarball for the architecture on which you are
+        developing.
+        If you are using an SDK type image, the image ships with the complete
+        toolchain native to the architecture (i.e. a toolchain designed to
+        run on the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>).
+        If you are not using an SDK type image, you need to separately download
+        and install the stand-alone Yocto Project cross-toolchain tarball.
     </para>
 
     <para>
-- 
cgit v1.2.3-54-g00ecf