[oe-commits] org.oe.documentation usermanual: Grammer and consistency edits.

lenehan commit openembedded-commits at lists.openembedded.org
Wed Aug 23 12:01:28 UTC 2006


usermanual: Grammer and consistency edits.

Author: lenehan at openembedded.org
Branch: org.openembedded.documentation
Revision: c23c92a45bf75bf4253fa4f05175a4aed000a601
ViewMTN: http://monotone.openembedded.org/revision.psp?id=c23c92a45bf75bf4253fa4f05175a4aed000a601
Files:
1
usermanual/reference/class_autotools.xml
usermanual/reference/class_binconfig.xml
usermanual/reference/class_image_ipkg.xml
usermanual/reference/class_pkgconfig.xml
usermanual/reference/class_rootfs_ipkg.xml
usermanual/reference/fakeroot.xml
usermanual/reference/image_types.xml
usermanual/reference/var_src_uri.xml
Diffs:

#
# mt diff -r2056cc912241d1bf1150525dded80fee8829c68a -rc23c92a45bf75bf4253fa4f05175a4aed000a601
#
# 
# 
# patch "usermanual/reference/class_autotools.xml"
#  from [dc2c77a6d1494610a6f6547e0c5523f4b96f4387]
#    to [79ebe0ad5dc5bbee6497bfd946a89eea7cf90770]
# 
# patch "usermanual/reference/class_binconfig.xml"
#  from [278e25491b7600aa1c467f61a97d27e2471354e2]
#    to [f17c4ab118a6d2457bee463e6935cba0deef8827]
# 
# patch "usermanual/reference/class_image_ipkg.xml"
#  from [65502f563079354aa7f1507d35976da85776e229]
#    to [a7b6966a38e7edf7627eff154408bb3b2ce937c7]
# 
# patch "usermanual/reference/class_pkgconfig.xml"
#  from [f1df8ee8b643f5dd83f1a77dd458d4dabd43fd0e]
#    to [7019c79baebb339f73c45065a47f5f843c129ebd]
# 
# patch "usermanual/reference/class_rootfs_ipkg.xml"
#  from [e166058cb654e624985572fcb9d31cc6329ed7d9]
#    to [b60f21722bc3b0055c3d2c3cd088a74da963aef4]
# 
# patch "usermanual/reference/fakeroot.xml"
#  from [8f3405a6dc46e163a1bdf5dfdb865ff07a6c7229]
#    to [f196de2fdd0e094314c24ad8c165cc336b67d299]
# 
# patch "usermanual/reference/image_types.xml"
#  from [5283afaac9d8dcf29c819d58c34bd9b61de04ab0]
#    to [b30ae757616222c06d39cf57ab21405241fec270]
# 
# patch "usermanual/reference/var_src_uri.xml"
#  from [1fe72055079ec0c3aa27702bdb01bcfb0411b716]
#    to [af5f400ee843c174305a38f187f577d8842108a6]
# 
============================================================
--- usermanual/reference/class_autotools.xml	dc2c77a6d1494610a6f6547e0c5523f4b96f4387
+++ usermanual/reference/class_autotools.xml	79ebe0ad5dc5bbee6497bfd946a89eea7cf90770
@@ -10,9 +10,9 @@
   options to specify search paths for headers and libraries.</para>
 
   <para>The autotools class takes care of all of the details for you. It
-  defines appropriate tasks for <command>do_configure</command>,
-  <command>do_compile</command>, <command>do_stage</command> and
-  <command>do_install</command>. At it's simplest adding an inherit for the
+  defines appropriate tasks for <emphasis>configure</emphasis>,
+  <emphasis>compile</emphasis>, <emphasis>stage</emphasis> and
+  <emphasis>install</emphasis>. At it's simplest adding an inherit for the
   autotools class is all that is required. The netcat recipe for example
   is:<screen>DESCRIPTION = "GNU Netcat"
 HOMEPAGE = "http://netcat.sourceforge.net"
@@ -24,17 +24,18 @@ inherit autotools</screen>The header is 
 SRC_URI = "${SOURCEFORGE_MIRROR}/netcat/netcat-${PV}.tar.bz2"
 
 inherit autotools</screen>The header is defined, the location of the source
-  code and then inherit. For the simplest cases that is all that is required.
-  If you need to pass addition parameters to the configure script, such as for
-  enabling and/or disabling options, then they can be specified via the
-  <command>EXTRA_OECONF</command> variable. This example from the lftp recipe
-  shows several extra options being passed to the configure script:<screen>EXTRA_OECONF = "--disable-largefile --disable-rpath --with-included-readline=no"</screen>If
-  you define your own tasks for <command>do_configure</command>,
-  <command>do_compile</command>, <command>do_stage</command> or
-  <command>do_install</command> then they will override the methods generated
-  by the autotools class. If you need to perform additional operations (rather
-  than replacing the generated operations) you can use the
-  <command>do_&lt;task&gt;_append</command> or
+  code and then the inherit. For the simplest cases this is all that is
+  required. If you need to pass additionol parameters to the configure script,
+  such as for enabling and/or disabling options, then they can be specified
+  via the <command>EXTRA_OECONF</command> variable. This example from the lftp
+  recipe shows several extra options being passed to the configure
+  script:<screen>EXTRA_OECONF = "--disable-largefile --disable-rpath --with-included-readline=no"</screen>If
+  you define your own tasks for <emphasis>configure</emphasis>,
+  <emphasis>compile</emphasis>, <emphasis>stage</emphasis> or
+  <emphasis>install</emphasis> (via <command>do_&lt;taskname&gt;</command>)
+  then they will override the methods generated by the autotools class. If you
+  need to perform additional operations (rather than replacing the generated
+  operations) you can use the <command>do_&lt;task&gt;_append</command> or
   <command>do_&lt;task&gt;_prepend</command> methods. The following example
   from the conserver recipe shows some additional items being
   installed:<screen># Include the init script and default settings in the package
@@ -51,9 +52,9 @@ do_install_append () {
     <command>oe_runconf</command> which runs the actual configure script, and
     a method called <command>autotools_do_configure</command> which generates
     the configure file (runs automake and autoconf) and then calls
-    <command>oe_runconf</command>. The generated
-    <command>do_configure</command> task just calls
-    autotools_do_configure.</para>
+    <command>oe_runconf</command>. The generated method for the
+    <emphasis>configure</emphasis> task, <command>do_configure</command>, just
+    calls the <command>autotools_do_configure</command> method.</para>
 
     <para>It is sometimes desirable to implement your own
     <command>do_configure</command> method, where additional configuration is
@@ -65,8 +66,8 @@ do_install_append () {
     oe_runconf
 }</screen>Sometimes manual manipulations of the autotools files is required
     prior to calling autoconf/automake. In this case you can defined your own
-    do_configure which performs the required actions and then calls
-    <command>autotools_do_configure</command>.</para>
+    <command>do_configure</command> method which performs the required actions
+    and then calls <command>autotools_do_configure</command>.</para>
   </section>
 
   <section>
============================================================
--- usermanual/reference/class_binconfig.xml	278e25491b7600aa1c467f61a97d27e2471354e2
+++ usermanual/reference/class_binconfig.xml	f17c4ab118a6d2457bee463e6935cba0deef8827
@@ -1,15 +1,15 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <section id="binconfig_class" xreflabel="binconfig class">
   <title>binconfig class</title>
 
   <para>The binconfig class is for packages that install
   <command>&lt;pkg&gt;-config</command> scripts that provide information about
-  the build settings for the package. It is usually provided by libraries
-  and then used by other packages to determine various compiler options.</para>
+  the build settings for the package. It is usually provided by libraries and
+  then used by other packages to determine various compiler options.</para>
 
   <para>Since the script is used at build time it is required to be copied
   into the staging area. All the actions performed by the class are appended
-  to the <emphasis>do_stage</emphasis> task.</para>
+  to the <emphasis>stage</emphasis> task.</para>
 
   <para>The actions performed by the binconfig class are:</para>
 
@@ -33,13 +33,14 @@
     </listitem>
   </orderedlist>
 
-  <para>A package is considered to be native it also inherits the native
+  <para>A package is considered to be native if it also inherits the native
   class.</para>
 
-  <para>The class will search in <command>${S}</command>, and all it's
-  subdirectories, for files that end in <command>-config</command> and process
-  them as described above. All that is required to use the class is the
-  addition of binconfig in an inherit statement:</para>
+  <para>The class will search in source directory, <command>${S}</command>,
+  and all it's subdirectories, for files that end in
+  <command>-config</command> and process them as described above. All that is
+  required to use the class is the addition of binconfig in an inherit
+  statement:</para>
 
   <para><screen>inherit autotools binconfig</screen></para>
 </section>
============================================================
--- usermanual/reference/class_image_ipkg.xml	65502f563079354aa7f1507d35976da85776e229
+++ usermanual/reference/class_image_ipkg.xml	a7b6966a38e7edf7627eff154408bb3b2ce937c7
@@ -1,13 +1,13 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <section id="image_ipkg_class" xreflabel="image_ipkg class">
   <title>image_ipkg class</title>
 
   <para>The image_ipkg class is used to generate images containing a root
-  filesystem, as generated by the <xref linkend="rootfs_ipkg_class" /> class,
-  for use on the target device. This could be a <emphasis>jffs2</emphasis>
-  image which is to be written into the flash on the target device for
-  example. In addition this class also configures the ipkg feeds (where to get
-  updates from) and is able to generate multiple different image types.</para>
+  filesystem, as generated by the <xref linkend="rootfs_ipkg_class" />, for
+  use on the target device. This could be a <emphasis>jffs2</emphasis> image
+  which is to be written into the flash on the target device for example. In
+  addition this class also configures the ipkg feeds (where to get updates
+  from) and is able to generate multiple different image types.</para>
 
   <para>Summary of actions performed by the <emphasis>image_ipkg</emphasis>
   class:</para>
@@ -48,7 +48,7 @@
     </listitem>
 
     <listitem>
-      <para>Call into <xref linkend="rootfs_ipkg_class" /> to install all of
+      <para>Calls into <xref linkend="rootfs_ipkg_class" /> to install all of
       the required components into the root filesystem;</para>
     </listitem>
 
@@ -58,7 +58,7 @@
     </listitem>
 
     <listitem>
-      <para>Run any image per-processing commands as specified via
+      <para>Runs any image pre-processing commands as specified via
       <command>${IMAGE_PREPROCESS_COMMAND}</command>;</para>
     </listitem>
 
@@ -70,7 +70,7 @@
     </listitem>
 
     <listitem>
-      <para>Run any image post-processing commands, as specified via
+      <para>Runs any image post-processing commands, as specified via
       <command>${IMAGE_POSTPROCESS_COMMAND}</command>.</para>
     </listitem>
   </orderedlist>
@@ -89,9 +89,9 @@
         filesystem, or not. If devfs is being used then no
         <command>/dev</command> directory will be required in the image. Set
         to <command>"1"</command> to indicate that devfs is being used. Note
-        that devfs has been removed from the Linux kernel 2.6 series and most
-        platforms are moving towards the use of udev as a replacement for
-        devfs.</para>
+        that devfs has been removed from the Linux kernel in the 2.6 series
+        and most platforms are moving towards the use of udev as a replacement
+        for devfs.</para>
 
         <para>Default: <command>"0"</command></para>
       </listitem>
@@ -102,12 +102,12 @@
 
       <listitem>
         <para>Specifies one, or more, files containing a list of the device
-        nodes that should be created in the /dev directory of the image. Each
-        file is searched for via the <command>${BBPATH}</command> and
-        therefore can be specified as a file relative to the top of the build.
-        Device files are processed in the specified order. NOTE: If
-        <command>IMAGE_DEVICE_TABLE</command> is set then this variable is
-        ignored.</para>
+        nodes that should be created in the <command>/dev</command> directory
+        of the image. Each file is searched for via the
+        <command>${BBPATH}</command> and therefore can be specified as a file
+        relative to the top of the build. Device files are processed in the
+        specified order. NOTE: If <command>IMAGE_DEVICE_TABLE</command> is set
+        then this variable is ignored.</para>
 
         <para>Example: <command>IMAGE_DEVICE_TABLES =
         "files/device_table-minimal.txt files/device_table_add-sci.txt
@@ -138,7 +138,7 @@
 
       <listitem>
         <para>Additional commands to run prior to processing the image. Note
-        that these command runs within the same <xref linkend="fakeroot" />
+        that these command run within the same <xref linkend="fakeroot" />
         instance as the rest of this class.</para>
 
         <para>Default: <command>""</command></para>
@@ -150,8 +150,8 @@
 
       <listitem>
         <para>Additional commands to run after processing the image. Note that
-        these command runs within the same <xref linkend="fakeroot" />
-        instance as the rest of this class.</para>
+        these command run within the same <xref linkend="fakeroot" /> instance
+        as the rest of this class.</para>
 
         <para>Default: <command>""</command></para>
       </listitem>
@@ -162,8 +162,9 @@
 
       <listitem>
         <para>Specifies the type of image files to create. The supported image
-        types and details on modify existing types and creating new types is
-        provided in the <xref linkend="image_types" /> section.</para>
+        types, and details on modifying existing types and on creating new
+        types, are described in the <xref linkend="image_types" />
+        section.</para>
 
         <para>Default: <command>"jffs2"</command></para>
       </listitem>
@@ -233,9 +234,9 @@ IMAGE_DEVICE_TABLES = "files/device_tabl
         <listitem>
           <para>This contains details for creating the
           <command>/dev/SC{0,1,2}</command> nodes which are required for the
-          SH processors on board SCI and SCIF serial ports. On the titan the
-          serial console is provided via one of these ports and so we require
-          the device node to be present.</para>
+          SH processors on board SCI and SCIF serial ports. On the titan
+          hardware the serial console is provided via one of these ports and
+          so we require the device node to be present.</para>
         </listitem>
       </varlistentry>
 
@@ -243,10 +244,11 @@ IMAGE_DEVICE_TABLES = "files/device_tabl
         <term>device_table_add-sm.txt</term>
 
         <listitem>
-          <para>This contains details fro creating the
+          <para>This contains details for creating the
           <command>/dev/sm0</command> and <command>/dev/sm0p{0,1,2}</command>
-          devices nodes for the block driver and associated partitions that is
-          used to managed the flash on the titan board.</para>
+          devices nodes for the block driver, and the associated partitions,
+          that are used to manage the on board flash on the titan
+          hardware.</para>
         </listitem>
       </varlistentry>
     </variablelist>
@@ -259,9 +261,10 @@ IMAGE_DEVICE_TABLES = "files/device_tabl
     <title>Image types</title>
 
     <para>The type of filesystem images to create are specified via the
-    IMAGE_FSTYPES variable. A full description of the available image types,
-    options of the images and details on creating new image types is provided
-    in the <xref linkend="image_types" /> section.</para>
+    <command>IMAGE_FSTYPES</command> variable. A full description of the
+    available image types, options of the images and details on creating new
+    image types is provided in the <xref linkend="image_types" />
+    section.</para>
   </section>
 
   <section>
@@ -270,8 +273,8 @@ IMAGE_DEVICE_TABLES = "files/device_tabl
     <para>Package feeds are used by the ipkg command to determine where to
     retrieve updates and new packages from.</para>
 
-    <para>Multiple feeds are support. Each is provided with a feed name and
-    the URL which will contain the packages. The following example shows the
+    <para>Multiple feeds are supported. Each feed provides a feed name and the
+    URL which will contain the packages. The following example shows the
     addition of two feeds, one called <emphasis>base</emphasis> and one called
     <emphasis>updates</emphasis>:</para>
 
============================================================
--- usermanual/reference/class_pkgconfig.xml	f1df8ee8b643f5dd83f1a77dd458d4dabd43fd0e
+++ usermanual/reference/class_pkgconfig.xml	7019c79baebb339f73c45065a47f5f843c129ebd
@@ -9,7 +9,7 @@
 
   <para>Since the contents of the file is used at build time it is required to
   be copied into the staging area. All the actions performed by the class are
-  appended to the <emphasis>do_stage</emphasis> task.</para>
+  appended to the <emphasis>stage</emphasis> task.</para>
 
   <para>The actions performed by the pkgconfig class are:</para>
 
@@ -27,12 +27,12 @@
     </listitem>
   </orderedlist>
 
-  <para>A package is consid%s
>>> DIFF TRUNCATED @ 16K






More information about the Openembedded-commits mailing list