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>
This commit is contained in:
Scott Rifenbark 2016-01-25 15:14:57 -08:00 committed by Richard Purdie
parent f15f96c07e
commit 890f7215f0
4 changed files with 128 additions and 25 deletions

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>