aboutsummaryrefslogtreecommitdiffstats
path: root/usermanual
diff options
context:
space:
mode:
authorHolger Freyther <zecke@selfish.org>2006-05-23 09:52:39 +0000
committerOpenEmbedded Project <openembedded-devel@lists.openembedded.org>2006-05-23 09:52:39 +0000
commit5b17940d3e284ab6841d7cddc25354bcc1223c27 (patch)
tree417314a1c6a670cf4fc7a133c631cd667472e3f0 /usermanual
parent0aae9fcd2eb8c69fb82a435cdd3935069afdd615 (diff)
parentc34aa546cc24bfc4d07a8bb10b0c21b5fbcd9a9a (diff)
downloadopenembedded-5b17940d3e284ab6841d7cddc25354bcc1223c27.tar.gz
merge of 1425bc04e3dac61b4754726249e5df756aa8445d
and be78973cd679f132cc2166ff1f88444ef5ade7ad
Diffstat (limited to 'usermanual')
-rw-r--r--usermanual/usermanual.xml13
1 files changed, 7 insertions, 6 deletions
diff --git a/usermanual/usermanual.xml b/usermanual/usermanual.xml
index fd7bdb7a9c..e101609344 100644
--- a/usermanual/usermanual.xml
+++ b/usermanual/usermanual.xml
@@ -167,8 +167,8 @@ It's important to use <emphasis>+=</emphasis> so it will get appended to the sta
<title>Getting OpenEmbedded</title>
<section>
<title>Getting <application>BitBake</application></title>
- <para>The requirement of the minimal version of <application>BitBake</application> required by OpenEmbedded is changing rapidly. At the time of writing (16th of May 2006) <application>BitBake</application> 1.4.2 was required.</para>
- <para>The most safe method is to <application>BitBake</application> from the stable Subversion branch of <application>BitBake</application>.
+ <para>The required version of <application>BitBake</application> is changing rapidly. At the time of writing (16th of May 2006) <application>BitBake</application> 1.4.2 was required.</para>
+ <para>A safe method is to get <application>BitBake</application> from the stable Subversion branch.
<screen>
<command>svn</command> co http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.4
...
@@ -176,7 +176,7 @@ A bitbake-1.4/classes/base.bbclass
U bitbake-1.4
Ausgecheckt, Revision 516.
</screen>
- We have now checked out <application>BitBake</application>; this completes the first and most critical dependency of OpenEmbedded. Issuing <command>svn</command> <command>up</command> in the <emphasis>bitbake-1.4</emphasis> directory will update <application>BitBake</application> to the latest stable version, but generally it is a good idea to stick with a specific known working version of <application>BitBake</application>. OpenEmbedded will warn you if your BitBake is getting too old.
+ <application>BitBake</application> is checked out now; this completes the first and most critical dependency of OpenEmbedded. Issuing <command>svn</command> <command>up</command> in the <emphasis>bitbake-1.4</emphasis> directory will update <application>BitBake</application> to the latest stable version, but generally it is a good idea to stick with a specific known working version of <application>BitBake</application> until OpenEmbedded asks you to upgrade.
</para>
</section>
@@ -452,12 +452,12 @@ needed library and use ${BOOTSTRAP_EXTRA_RDEPENDS} to make sure this package is
<section>
<title>buildroot</title>
- <para>We are better, they are on crack?</para>
+ <para>Writing of <application>BitBake</application> recipes is more easy and more intuitive than writing Makefiles while providing higher flexibility. This allows you to tweak specific recipes for your very special needs and to add new recipes very fast. You can build toolchains, Software Distribution Kits (SDKs), complete Distributions or just single packages. The flexibility of OpenEmbedded allows you to reuse the once written recipes for many different purposes. OpenEmbedded provides everything buildroot will be able to provide. But in contrast to buildroot OpenEmbedded will allow you to achieve what you really want to achieve. You can add new package formats, new filesystems, new output formats easily. OpenEmbedded will suit your need.</para>
</section>
<section>
<title>crosstool</title>
- <para>We are better, they are on crack?</para>
+ <para>Crosstool allows to create toolchains for you. It can only create the initial toolchain for you. It will not compile other needed libraries or applications for you, it will not be able to track dependencies or to package them properly. OpenEmbedded supports all configurations crosstool supports. You can start to create toolchains with OpenEmbedded, then as your needs grow create a more complete SDK from already present base libraries and applications and if you recognize you need to have packages for the target you have them almost built already.</para>
</section>
<section>
@@ -466,7 +466,8 @@ needed library and use ${BOOTSTRAP_EXTRA_RDEPENDS} to make sure this package is
the buildsystem they use to build their software. This will lead to a variety of issues you can run into. This can be failing
tests on configuration because of executing cross compiled binaries or crashes at run-time due wrong sizes of basic types.
When utilizing OpenEmbedded you avoid searching for patches at many different places and will be able to get things done more quickly.
-<application>OpenEmbedded</application> allows you to choose from a pool of ready to use software packages, allow creation of images and many more.</para>
+<application>OpenEmbedded</application> allows you to choose from a pool of ready to use software packages.</para>
+ <para>OpenEmbedded will create complete flashable images using different output formats and filesystems. This allows you to create complete and specialized distributions easily.</para>
</section>
</chapter>
</book>