sdk-manual: WIP - Various small edits as WIP

(From yocto-docs rev: 53c16de81028d5564a75b4787203d6862258f68e)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/sdk-manual/sdk-appendix-obtain.xml

@@ -12,6 +12,8 @@
     It is debatable as to whether or not this should be an appendix.
     It could be part of a main chapter I think.
     Originally suggested by Paul that it should be an appendix.
+    I have a sub-section in the main chapters to cover this should we
+    decide to place it there.
 </para>
 
 <para>
@@ -22,8 +24,8 @@
 <para>
     One thing that needs discussed is any differences between getting the
     standard SDK as compared to the extended SDK.
-    Do we have pre-build extended SDKs laying around?
+    Do we have pre-build extensible SDKs laying around?
-    Where do we get any pre-build SDKs from?
+    Where do we get any pre-built SDKs from?
     Show the methods by which the user builds out the SDK?
 </para>
 

documentation/sdk-manual/sdk-extensible.xml

@@ -7,22 +7,56 @@
 <title>Using the Extensible SDK</title>
 
 <para>
-    This chapter is going to cover all the SDK stuff that is unique
+    This chapter describes what you need on your machine in order to use
-    to the extensible SDK.
+    an extensible SDK.
+    The chapter does not repeat information that also applies to using the
+    standard SDK.
+    The chapter also includes procedures of tasks you can perform using
+    an extensible SDK.
+    <note>
+        The tasks you can perform using a standard SDK are also available
+        using an extensible SDK.
+        For information on using the standard SDK, see the
+        "<link linkend='sdk-using-the-standard-sdk'>Using the Standard SDK</link>"
+        chapter.
+    </note>
 </para>
 
+
 <section id='sdk-setting-up-to-use-the-extensible-sdk'>
     <title>Setting Up to Use the Extensible SDK</title>
 
     <para>
-        What do you need to use the extensible SDK that is different from
+        Here is a list of items I think need addressed in this section:
-        the standard SDK?
+        <itemizedlist>
-        What does your system have to have on it?
+            <listitem><para><emphasis>Cover differences in the development
-        What are the recommendations?
+                that might be impacted because they are using an extensible
-        What conditions in your development scenario warrant use of just the
+                SDK</emphasis></para>
-        extensible SDK?
+                <para>Presumably, the various development scenarios are
-        Show any specific procedures needed to get set up to use the
+                covered regarding setup in the previous chapter.
-        extensible SDK.
+                Are these impacted because the developer is going to now be
+                using an extensible SDK?
+                If so, what are the implications?
+                </para></listitem>
+            <listitem><para><emphasis>What new recommendations exist now that
+                the developer is going to be using an extensible SDK?</emphasis></para>
+                <para>We should cover the most common development scenarios
+                that apply when using an extensible SDK.
+                Is there a recommended development flow we want to present
+                when using an extensible SDK?
+                What conditions in a development scenario warrant use of
+                the extensible SDK as compared to the standard SDK?
+                </para></listitem>
+            <listitem><para><emphasis>What procedures do we want to cover to set
+                up the extensible SDK?</emphasis></para>
+                <para>Is it just a matter of building out the SDK using
+                <filename>bitbake -c populate_sdk_ext</filename>?
+                Is there a pre-built extensible SDK laying around they can
+                find and download if they are using a machine that does not
+                have YP installed, which would prevent them from building their
+                own SDK?
+                </para></listitem>
+        </itemizedlist>
     </para>
 </section>
 

documentation/sdk-manual/sdk-intro.xml

@@ -27,7 +27,19 @@
     </para>
 
     <para>
-        Describe what a standard SDK is as compared to the extensible SDK.
+        A standard SDK consists of a cross-development toolchain that contains
+        a compiler, debugger, and various miscellaneous tools; libraries,
+        headers, and symbols to match an image; and environment setup script.
+        You can use this SDK to independently develop and test code that is
+        destined to run on some target machine.
+    </para>
+
+    <para>
+        An extensible SDK consists of everything that the standard SDK has plus
+        tools that allow you to easily add new applications and libraries to
+        an image, modify the source of an existing component, test changes on
+        the target hardware, and easily integrate an application into the
+        the Yocto Project build system.
     </para>
 </section>
 
@@ -35,10 +47,27 @@
     <title>SDK Development Model</title>
 
     <para>
-        * Development Model - provide a figure that shows the development
+        Fundamentally, the SDK fits into the development process as follows:
-          pieces using boxes and arrows.
+        <imagedata fileref="figures/sdk-environment.png" align="center" width="6in" depth="5in" scalefit="100" />
-          Include all possible methods, inputs and outputs.
+        The SDK is installed on any machine and can be used to develop
-          <imagedata fileref="figures/sdk-environment.png" align="center" width="6in" depth="5in" scalefit="100" />
+        applications, images, and kernels.
+        An SDK can even be used by a QA Engineer or Release Engineer.
+        The fundamental concept is that the machine that has the SDK installed
+        does not have to be associated with the machine that has the
+        Yocto Project installed.
+        A developer can independently compile and test an object on their
+        machine and then, when the object is ready for integration into an
+        image, they can simply make it available to the machine that has the
+        the Yocto Project.
+        Once the object is available, the image can be rebuilt using the
+        Yocto Project to produce the modified image.
+    </para>
+
+    <para>
+        The remainder of this manual describes how to use both the standard
+        SDK and the extensible SDK.
+        Information also exists in appendix form that describes how you can
+        build, install, and modify an SDK.
     </para>
 </section>
 

documentation/sdk-manual/sdk-using.xml

@@ -7,20 +7,58 @@
 <title>Using the Standard SDK</title>
 
 <para>
-    This chapter is going to cover all the SDK stuff that is common
+    This chapter describes how to use a standard SDK.
-    to both the SDK and the extensible SDK.
+    Information covers installing the SDK and task-based procedures common
+    for developing with a standard SDK.
+    <note>
+        The tasks you can perform using a standard SDK are also applicable
+        when you are using an extensible SDK.
+        For information on the differences when using an extensible SDK as
+        compared to an extensible SDK, see the
+        "<link linkend='sdk-extensible'>Using the Extensible SDK</link>"
+        chapter.
+    </note>
 </para>
 
 <section id='sdk-setting-up-to-use-the-standard-sdk'>
     <title>Setting Up to Use the Standard SDK</title>
 
     <para>
-        What do you need to use the SDK?
+        Here is a list of items I think need addressed in this section:
-        What does your system have to have on it?
+        <itemizedlist>
-        What are the recommendations?
+            <listitem><para><emphasis>What is your situation?</emphasis></para>
-        What conditions in your development scenario warrant use of just the
+                <para>In other words, is the developer on a machine that
-        standard SDK as compared to the extensible SDK?
+                has YP on it?
-        Show any specific procedures needed to get set up to use the SDK.
+                Are they on a machine that does not?
+                Is the image they are developing against available as a
+                pre-built, down-loadable image and can they get it?</para>
+                <para>Depending on the scenario, there are different ways
+                to make sure the machine they are using is ready to use a
+                standard SDK.
+                I think we need to cover the various situations in this
+                section.
+                </para></listitem>
+            <listitem><para><emphasis>What are the recommendations?</emphasis></para>
+                <para>What is the most common development scenario?
+                Is there a recommended development flow we want to present
+                when using a standard SDK?
+                What conditions in a development scenario warrant use of
+                just the standard SDK as compared to the extensible SDK?
+                </para></listitem>
+            <listitem><para><emphasis>What procedures do we want to cover to set up
+                the standard SDK?</emphasis></para>
+                <para>There is a ton of setup information in the
+                current ADT manual regarding getting, building, and installing
+                an SDK.
+                We would ignore the stuff about the ADT installer script
+                since I presume that is going away.
+                But, there are steps to download and existing
+                <filename>.sh</filename> install script, build out the
+                toolchains assuming your system has YP on it and you can run
+                BitBake, getting the root filesystem, getting an image so you
+                run QEMU on your system, etc.
+                </para></listitem>
+        </itemizedlist>
     </para>
 </section>