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>
<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>
<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>
</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>
<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>
<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>
projects / thirdparty / openembedded / openembedded-core-contrib.git / commitdiff
