documentation/dev-manual/dev-manual-bsp-appendix.xml: Edits to examples
Updated the tarball and Git repo example in section where user is getting the source files. I was not using the default Yocto Project Files top-level name for the tarball method. Reported-by: Joshua.lock <joshua.lock@intel.com> (From yocto-docs rev: 770c6799ea58df3d81df8f466f1bb9878532a995) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
deddea16d2
commit
4d09a3c211
|
@ -35,15 +35,20 @@
|
|||
|
||||
<para>
|
||||
As mentioned, one way to get the Yocto Project files is to use Git to clone the
|
||||
<filename>poky</filename> repository:
|
||||
<filename>poky</filename> repository.
|
||||
These commands create a local copy of the Git repository.
|
||||
By default, the top-level directory of the repository is named <filename>poky</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ git clone git://git.yoctoproject.org/poky
|
||||
$ cd poky
|
||||
</literallayout>
|
||||
Alternatively, you can start with the downloaded Poky "edison" tarball:
|
||||
Alternatively, you can start with the downloaded Poky "edison" tarball.
|
||||
These commands unpack the tarball into a Yocto Project File directory structure.
|
||||
By default, the top-level directory of the file structure is named
|
||||
<filename>poky-edison-6.0</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ tar xfj poky-edison-6.0.tar.bz2
|
||||
$ cd poky
|
||||
$ cd poky-edison-6.0
|
||||
</literallayout>
|
||||
<note><para>If you're using the tarball method, you can ignore all the following steps that
|
||||
ask you to carry out Git operations.
|
||||
|
@ -56,8 +61,12 @@
|
|||
that represents a specific release.
|
||||
Fundamentally, this is different than having a local copy of the Yocto Project
|
||||
Git repository.
|
||||
Given the tarball method, changes you make are building on top of a release, while
|
||||
you are tracking development when you use the Git repository method.</para></note>
|
||||
Given the tarball method, changes you make are building on top of a release.
|
||||
With the Git repository method you have the ability to track development
|
||||
and keep changes in revision control.
|
||||
See the
|
||||
"<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>" section
|
||||
for more discussion around these differneces.</para></note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -66,7 +75,8 @@
|
|||
Next, you need to be sure that your local repository reflects the exact
|
||||
release in which you are interested.
|
||||
From inside the repository you can see the development branches that represent
|
||||
areas of development that have diverged from the main (master) branch.
|
||||
areas of development that have diverged from the main (master) branch
|
||||
at some point, such as a branch to track a maintenance release's development.
|
||||
You can also see the tag names used to mark snapshots of stable releases or
|
||||
points in the repository.
|
||||
Use the following commands to list out the branches and the tags in the repository,
|
||||
|
|
Loading…
Reference in New Issue