documentation/dev-manual/dev-manual-bsp-appendix.xml: Yocto term scrub

Scrubbed the manual for the term "Yocto Project", which has been
over-used.  I updated occurrances to better represent actual bits
rather than generically referring to everything as Yocto Project.

(From yocto-docs rev: f70cffeffa0d8863a88783607621bf6f7125d02d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 21 insertions, 22 deletions

diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml
index ec8fe1463a..e3f8f7664c 100644
--- a/documentation/dev-manual/dev-manual-bsp-appendix.xml
+++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml
@@ -23,19 +23,20 @@
 </para>
 
 <section id='getting-local-yocto-project-files-and-bsp-files'>
-    <title>Getting Local Yocto Project Files and BSP Files</title>
+    <title>Getting Local Source Files and BSP Files</title>
 
     <para>
-        You need to have the Yocto Project files available on your host system.  
-        You can get files through tarball extraction or by cloning the <filename>poky</filename>
-        Git repository.
+        You need to have the <link linkend='source-directory'>source directory</link>
+        available on your host system.  
+        You can set up this directory through tarball extraction or by cloning the 
+        <filename>poky</filename> Git repository.
         The following paragraphs describe both methods.
         For additional information, see the bulleted item
         "<link linkend='local-yp-release'>Yocto Project Release</link>".
     </para> 
 
     <para>
-        As mentioned, one way to get the Yocto Project files is to use Git to clone the 
+        As mentioned, one way to set up the source directory is to use Git to clone the 
         <filename>poky</filename> repository. 
         These commands create a local copy of the Git repository.
         By default, the top-level directory of the repository is named <filename>poky</filename>:
@@ -44,8 +45,8 @@
      $ cd poky
         </literallayout> 
         Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball.
-        These commands unpack the tarball into a Yocto Project File directory structure.
-        By default, the top-level directory of the file structure is named
+        These commands unpack the tarball into a source directory structure.
+        By default, the top-level directory of the source directory is named
         <filename>&YOCTO_POKY;</filename>:
         <literallayout class='monospaced'>
      $ tar xfj &YOCTO_POKY_TARBALL;
@@ -60,8 +61,7 @@
 
         <para>Once you expand the released tarball, you have a snapshot of the Git repository
         that represents a specific release.
-        Fundamentally, this is different than having a local copy of the Yocto Project 
-        Git repository.  
+        Fundamentally, this is different than having a local copy of the Poky Git repository.  
         Given the tarball method, changes you make are building on top of a release.
         With the Git repository method you have the ability to track development
         and keep changes in revision control.
@@ -133,12 +133,12 @@
 
     <para>
         You need to have the base BSP layer on your development system.  
-        Similar to the local <link linkend='yocto-project-files'>Yocto Project Files</link>, 
+        Similar to the local <link linkend='source-directory'>source directory</link>, 
         you can get the BSP 
         layer in a couple of different ways:  
         download the BSP tarball and extract it, or set up a local Git repository that 
-        has the Yocto Project BSP layers.  
-        You should use the same method that you used to get the local Yocto Project files earlier.
+        has the BSP layers.  
+        You should use the same method that you used to set up the source directory earlier.
         See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get 
         the BSP files.
     </para>
@@ -196,8 +196,8 @@
     <title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
 
     <para>
-        Now that you have the local Yocto Project files and the base BSP files, you need to create a 
-        new layer for your BSP.
+        Now that you have set up the source directory and included the base BSP files, you need to 
+        create a new layer for your BSP.
         To create your BSP layer, you simply copy the <filename>meta-crownbay</filename>
         layer to a new layer.
     </para>
@@ -207,7 +207,7 @@
         The name should follow the BSP layer naming convention, which is 
         <filename>meta-&lt;name&gt;</filename>.  
         The following assumes your working directory is <filename>meta-intel</filename> 
-        inside the local Yocto Project files.  
+        inside your source directory.  
         To start your new layer, just copy the new layer alongside the existing
         BSP layers in the <filename>meta-intel</filename> directory:
         <literallayout class='monospaced'>
@@ -239,7 +239,7 @@
             First, since in this example the new BSP will not support EMGD, we will get rid of the 
             <filename>crownbay.conf</filename> file and then rename the 
             <filename>crownbay-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.  
-            Much of what we do in the configuration directory is designed to help the Yocto Project 
+            Much of what we do in the configuration directory is designed to help the OpenEmbedded 
             build system work with the new layer and to be able to find and use the right software.  
             The following two commands result in a single machine configuration file named 
             <filename>mymachine.conf</filename>.  
@@ -312,7 +312,7 @@
             When you create a BSP, you use these areas for appropriate recipes and append files.  
             Recipes take the form of <filename>.bb</filename> files, while append files take
             the form of <filename>.bbappend</filename> files.  
-            If you want to leverage the existing recipes the Yocto Project build system uses
+            If you want to leverage the existing recipes the OpenEmbedded build system uses
             but change those recipes, you can use <filename>.bbappend</filename> files.  
             All new recipes and append files for your layer must go in the layer’s 
             <filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>, 
@@ -365,7 +365,7 @@
                 Now let's look at changes in <filename>recipes-core</filename>.
                 The file <filename>task-core-tools.bbappend</filename> in 
                 <filename>recipes-core/tasks</filename> appends the similarly named recipe
-                located in the local <link linkend='yocto-project-files'>Yocto Project Files</link> at 
+                located in the <link linkend='source-directory'>source directory</link> at 
                 <filename>meta/recipes-core/tasks</filename>.
                 The append file in our layer right now is Crown Bay-specific and supports 
                 EMGD and non-EMGD.
@@ -395,7 +395,7 @@
                 Recall that the BSP uses the <filename>linux-yocto</filename> kernel as determined
                 earlier in the <filename>mymachine.conf</filename>.
                 The recipe for that kernel is not located in the  
-                BSP layer but rather in the local Yocto Project files at 
+                BSP layer but rather in the source directory at 
                 <filename>meta/recipes-kernel/linux</filename> and is 
                 named <filename>linux-yocto_3.2.bb</filename>.
                 The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
@@ -576,15 +576,14 @@
         <orderedlist>
             <listitem><para>Get the environment ready for the build by sourcing the environment 
                 script. 
-                The environment script is in the top-level of the local Yocto Project files
-                directory structure.
+                The environment script is in the top-level of the source directory.
                 The script has the string 
                 <filename>init-build-env</filename> in the file’s name.  
                 For this example, the following command gets the build environment ready:                       
                 <literallayout class='monospaced'>
      $ source oe-init-build-env yocto-build
                 </literallayout>
-                When you source the script a build directory is created in the current 
+                When you source the script, a build directory is created in the current 
                 working directory.  
                 In our example we were in the <filename>poky</filename> directory.  
                 Thus, entering the previous command created the <filename>yocto-build</filename> directory.