documentation: dev-manual - Final changes before 1.3 lockdown.

Made minor changes as needed due to some new sections, links,
and capitalization standards.

(From yocto-docs rev: bc966e5a78dadd14ecf1896a36e40a9b256bae77)

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

1 files changed, 29 insertions, 23 deletions

diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 20cf234a6b..bb01131c05 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -130,7 +130,7 @@
         From the interface, you can click on any particular item in the "Name" column and 
         see the URL at the bottom of the page that you need to set up a Git repository for 
         that particular item.
-        Having a local Git repository of the source directory (poky) allows you to 
+        Having a local Git repository of the Source Directory (poky) allows you to 
         make changes, contribute to the history, and ultimately enhance the Yocto Project's 
         tools, Board Support Packages, and so forth.
     </para>
@@ -148,7 +148,7 @@
         <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink> and get a 
         tarball of the release.  
         You can also go to this site to download any supported BSP tarballs.
-        Unpacking the tarball gives you a hierarchical source directory that lets you develop 
+        Unpacking the tarball gives you a hierarchical Source Directory that lets you develop 
         using the Yocto Project.
     </para>
 
@@ -220,31 +220,31 @@
                 <para id='build-directory'><emphasis>Build Directory:</emphasis>
                 This term refers to the area used by the OpenEmbedded build system for builds.  
                 The area is created when you <filename>source</filename> the setup 
-                environment script that is found in the source directory
-                (i.e. <filename>oe-init-build-env</filename>).
+                environment script that is found in the Source Directory
+                (i.e. <filename>&OE_INIT_FILE;</filename>).
                 The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
-                variable points to the build directory.</para>
+                variable points to the Build Directory.</para>
            
-                <para>You have a lot of flexibility when creating the build directory.
+                <para>You have a lot of flexibility when creating the Build Directory.
                 Following are some examples that show how to create the directory:
                    <itemizedlist>
-                        <listitem><para>Create the build directory in your current working directory
+                        <listitem><para>Create the Build Directory in your current working directory
                             and name it <filename>build</filename>.
                             This is the default behavior.
                             <literallayout class='monospaced'>
-     $ source oe-init-build-env
+     $ source &OE_INIT_PATH;
                             </literallayout></para></listitem>
                         <listitem><para>Provide a directory path and specifically name the build 
                             directory. 
-                            This next example creates a build directory named <filename>YP-&POKYVERSION;</filename>
+                            This next example creates a Build Directory named <filename>YP-&POKYVERSION;</filename>
                             in your home directory within the directory <filename>mybuilds</filename>.
                             If <filename>mybuilds</filename> does not exist, the directory is created for you:
                             <literallayout class='monospaced'> 
      $ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION;
                             </literallayout></para></listitem>
-                        <listitem><para>Provide an existing directory to use as the build directory.
+                        <listitem><para>Provide an existing directory to use as the Build Directory.
                             This example uses the existing <filename>mybuilds</filename> directory 
-                            as the build directory.
+                            as the Build Directory.
                             <literallayout class='monospaced'> 
      $ source &OE_INIT_PATH; $HOME/mybuilds/
                             </literallayout></para></listitem>
@@ -254,7 +254,7 @@
                 this term refers to the OpenEmbedded build system used by the project. 
                 This build system is based on the project known as "Poky."
                 For some historical information about Poky, see the 
-                <link linkend='poky'>poky</link> term further along in this section.
+                <link linkend='poky'>Poky</link> term further along in this section.
                 </para></listitem>
             <listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
                 and inheritance allowing commonly used patterns to be defined once and easily used 
@@ -264,14 +264,14 @@
             <listitem><para><emphasis>Configuration File:</emphasis>  Configuration information in various
                 <filename>.conf</filename> files provides global definitions of variables.
                 The <filename>conf/local.conf</filename> configuration file in the 
-                <link linkend='build-directory'>build directory</link>
+                <link linkend='build-directory'>Build Directory</link>
                 contains user-defined variables that affect each build.
                 The <filename>meta-yocto/conf/distro/poky.conf</filename> configuration file
                 defines Yocto ‘distro’ configuration
                 variables used only when building with this policy.  
                 Machine configuration files, which 
                 are located throughout the 
-                <link linkend='source-directory'>source directory</link>, define
+                <link linkend='source-directory'>Source Directory</link>, define
                 variables for specific hardware and are only used when building for that target 
                 (e.g. the <filename>machine/beagleboard.conf</filename> configuration file defines 
                 variables for the Texas Instruments ARM Cortex-A8 development board).  
@@ -332,7 +332,7 @@
                 the Yocto Project's build system.
                 Within the Yocto Project source repositories, poky exists as a separate Git repository
                 that can be cloned to yield a local copy on the host system. 
-                Thus, "poky" can refer to the local copy of the source directory used to develop within
+                Thus, "poky" can refer to the local copy of the Source Directory used to develop within
                 the Yocto Project.</para></listitem>
             <listitem><para><emphasis>Recipe:</emphasis> A set of instructions for building packages.  
                 A recipe describes where you get source code and which patches to apply.
@@ -349,15 +349,15 @@
                 Sometimes you might here the term "poky directory" used to refer to this 
                 directory structure.</para>
 
-                <para>The source directory contains BitBake, Documentation, metadata and 
+                <para>The Source Directory contains BitBake, Documentation, metadata and 
                 other files that all support the Yocto Project. 
-                Consequently, you must have the source directory in place on your development 
+                Consequently, you must have the Source Directory in place on your development 
                 system in order to do any development using the Yocto Project.</para>
 
-                <para>For tarball expansion, the name of the top-level directory of the source directory  
+                <para>For tarball expansion, the name of the top-level directory of the Source Directory  
                 is derived from the Yocto Project release tarball.
                 For example, downloading and unpacking <filename>&YOCTO_POKY_TARBALL;</filename>
-                results in a source directory whose top-level folder is named 
+                results in a Source Directory whose top-level folder is named 
                 <filename>&YOCTO_POKY;</filename>.
                 If you create a local copy of the Git repository, then you can name the repository 
                 anything you like.
@@ -366,15 +366,15 @@
                 So, for example, cloning the <filename>poky</filename> Git repository results in a 
                 local Git repository whose top-level folder is also named <filename>poky</filename>.</para>
 
-                <para>It is important to understand the differences between the source directory created
+                <para>It is important to understand the differences between the Source Directory created
                 by unpacking a released tarball as compared to cloning 
                 <filename>git://git.yoctoproject.org/poky</filename>.
                 When you unpack a tarball, you have an exact copy of the files based on the time of 
                 release - a fixed release point.
-                Any changes you make to your local files in the source directory are on top of the release.
+                Any changes you make to your local files in the Source Directory are on top of the release.
                 On the other hand, when you clone the <filename>poky</filename> Git repository, you have an
                 active development repository.
-                In this case, any local changes you make to the source directory can be later applied 
+                In this case, any local changes you make to the Source Directory can be later applied 
                 to active development branches of the upstream <filename>poky</filename> Git 
                 repository.</para>
 
@@ -438,7 +438,7 @@
         <filename>meta/files/common-licenses</filename>.  
         Once the build completes, the list of all licenses found and used during that build are 
         kept in the 
-        <link linkend='build-directory'>build directory</link> at 
+        <link linkend='build-directory'>Build Directory</link> at 
         <filename>tmp/deploy/images/licenses</filename>.
     </para>
 
@@ -466,6 +466,12 @@
         <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
         This wiki page discusses the license infrastructure used by the Yocto Project.
     </para>
+
+    <para>
+        For information that can help you to maintain compliance with various open source licensing 
+        during the lifecycle of a product created using the Yocto Project, see the 
+        "<link linkend='maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</link>" section.
+    </para>
 </section>
 
 <section id='git'>