diff options
author | Scott Rifenbark <srifenbark@gmail.com> | 2016-01-25 15:14:57 -0800 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2016-03-23 21:56:07 +0000 |
commit | 890f7215f015385762bce7c97b192f6a68d74585 (patch) | |
tree | 16ef33a768cfd9d4bfd7d69d9da2d463c652454f /documentation | |
parent | f15f96c07ebf9468001c63a35b688311787f3467 (diff) | |
download | openembedded-core-contrib-890f7215f015385762bce7c97b192f6a68d74585.tar.gz |
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>
Diffstat (limited to 'documentation')
-rw-r--r-- | documentation/sdk-manual/sdk-appendix-obtain.xml | 6 | ||||
-rw-r--r-- | documentation/sdk-manual/sdk-extensible.xml | 54 | ||||
-rw-r--r-- | documentation/sdk-manual/sdk-intro.xml | 39 | ||||
-rw-r--r-- | documentation/sdk-manual/sdk-using.xml | 54 |
4 files changed, 128 insertions, 25 deletions
diff --git a/documentation/sdk-manual/sdk-appendix-obtain.xml b/documentation/sdk-manual/sdk-appendix-obtain.xml index fbdb240368..a9996c4d18 100644 --- a/documentation/sdk-manual/sdk-appendix-obtain.xml +++ b/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? - Where do we get any pre-build SDKs from? + Do we have pre-build extensible SDKs laying around? + Where do we get any pre-built SDKs from? Show the methods by which the user builds out the SDK? </para> diff --git a/documentation/sdk-manual/sdk-extensible.xml b/documentation/sdk-manual/sdk-extensible.xml index 4236b165b5..a04164a413 100644 --- a/documentation/sdk-manual/sdk-extensible.xml +++ b/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 - to the extensible SDK. + This chapter describes what you need on your machine in order to use + 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 - the standard SDK? - What does your system have to have on it? - What are the recommendations? - What conditions in your development scenario warrant use of just the - extensible SDK? - Show any specific procedures needed to get set up to use the - extensible SDK. + Here is a list of items I think need addressed in this section: + <itemizedlist> + <listitem><para><emphasis>Cover differences in the development + that might be impacted because they are using an extensible + SDK</emphasis></para> + <para>Presumably, the various development scenarios are + covered regarding setup in the previous chapter. + 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> diff --git a/documentation/sdk-manual/sdk-intro.xml b/documentation/sdk-manual/sdk-intro.xml index 99f807e056..5b12fcff64 100644 --- a/documentation/sdk-manual/sdk-intro.xml +++ b/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 - pieces using boxes and arrows. - Include all possible methods, inputs and outputs. - <imagedata fileref="figures/sdk-environment.png" align="center" width="6in" depth="5in" scalefit="100" /> + Fundamentally, the SDK fits into the development process as follows: + <imagedata fileref="figures/sdk-environment.png" align="center" width="6in" depth="5in" scalefit="100" /> + The SDK is installed on any machine and can be used to develop + 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> diff --git a/documentation/sdk-manual/sdk-using.xml b/documentation/sdk-manual/sdk-using.xml index eb024f917c..e3dc6e22a1 100644 --- a/documentation/sdk-manual/sdk-using.xml +++ b/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 - to both the SDK and the extensible SDK. + This chapter describes how to use a standard 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? - What does your system have to have on it? - What are the recommendations? - What conditions in your development scenario warrant use of just the - standard SDK as compared to the extensible SDK? - Show any specific procedures needed to get set up to use the SDK. + Here is a list of items I think need addressed in this section: + <itemizedlist> + <listitem><para><emphasis>What is your situation?</emphasis></para> + <para>In other words, is the developer on a machine that + has YP on it? + 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> |