diff options
Diffstat (limited to 'usermanual/reference')
| -rw-r--r-- | usermanual/reference/class_autotools.xml | 39 | ||||
| -rw-r--r-- | usermanual/reference/class_binconfig.xml | 17 | ||||
| -rw-r--r-- | usermanual/reference/class_image_ipkg.xml | 69 | ||||
| -rw-r--r-- | usermanual/reference/class_pkgconfig.xml | 14 | ||||
| -rw-r--r-- | usermanual/reference/class_rootfs_ipkg.xml | 27 | ||||
| -rw-r--r-- | usermanual/reference/fakeroot.xml | 43 | ||||
| -rw-r--r-- | usermanual/reference/image_types.xml | 51 | ||||
| -rw-r--r-- | usermanual/reference/var_src_uri.xml | 48 |
8 files changed, 158 insertions, 150 deletions
diff --git a/usermanual/reference/class_autotools.xml b/usermanual/reference/class_autotools.xml index 2614209045..36b377a14a 100644 --- a/usermanual/reference/class_autotools.xml +++ b/usermanual/reference/class_autotools.xml @@ -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 @@ PR = "r1" 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_<task>_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_<taskname></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_<task>_append</command> or <command>do_<task>_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> diff --git a/usermanual/reference/class_binconfig.xml b/usermanual/reference/class_binconfig.xml index 618f9fefd1..049f85e1f0 100644 --- a/usermanual/reference/class_binconfig.xml +++ b/usermanual/reference/class_binconfig.xml @@ -4,12 +4,12 @@ <para>The binconfig class is for packages that install <command><pkg>-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>
\ No newline at end of file diff --git a/usermanual/reference/class_image_ipkg.xml b/usermanual/reference/class_image_ipkg.xml index 31eb2e6f29..fa11e0801e 100644 --- a/usermanual/reference/class_image_ipkg.xml +++ b/usermanual/reference/class_image_ipkg.xml @@ -3,11 +3,11 @@ <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_table-minimal.txt files/device_table_add-sci <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_table-minimal.txt files/device_table_add-sci <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_table-minimal.txt files/device_table_add-sci <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_table-minimal.txt files/device_table_add-sci <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> diff --git a/usermanual/reference/class_pkgconfig.xml b/usermanual/reference/class_pkgconfig.xml index 08df975b84..d4334a063b 100644 --- a/usermanual/reference/class_pkgconfig.xml +++ b/usermanual/reference/class_pkgconfig.xml @@ -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 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>.pc</command> (it will ignore - those that end in <command>-uninstalled.pc)</command> and process them as - described above. All that is required to use the class is the addition of - pkgconfig in an inherit statement:<screen>inherit autotools pkgconfig</screen></para> + <para>The class will search in source directory, <command>${S}</command>, + and all it's subdirectories, for files that end in <command>.pc</command> + (it will ignore those that end in <command>-uninstalled.pc)</command> and + process them as described above. All that is required to use the class is + the addition of pkgconfig in an inherit statement:<screen>inherit autotools pkgconfig</screen></para> </section>
\ No newline at end of file diff --git a/usermanual/reference/class_rootfs_ipkg.xml b/usermanual/reference/class_rootfs_ipkg.xml index 40a17acfe2..0b1e9875c2 100644 --- a/usermanual/reference/class_rootfs_ipkg.xml +++ b/usermanual/reference/class_rootfs_ipkg.xml @@ -4,20 +4,19 @@ <para>The <emphasis>rootf_ipk</emphasis> class us used to create a root filesystem for the target device from a set of .ipkg packages. The end - result is a directory containing all the files that need to be packages that - would need to be included in the root filesystem of the target - device.</para> + result is a directory containing all the files that need to be included in + the root filesystem of the target device.</para> - <para>This class is normally not useddirectly, but instead used from - the<xref linkend="image_ipkg_class" /> which creates disk images from a set - of <command>.ipkg</command> files.</para> + <para>This class is normally not used directly, but instead used from the + <xref linkend="image_ipkg_class" /> which creates images from a set of + <command>.ipkg</command> files.</para> <para>Summary of actions performed by the <emphasis>rootfs_ipkg</emphasis> class:</para> <orderedlist> <listitem> - <para>Erase an existing root filesyste image by deleting the entire + <para>Erase any existing root filesystem image by deleting the entire contents of <command>${IMAGE_ROOTFS}</command>;</para> </listitem> @@ -37,11 +36,11 @@ </listitem> <listitem> - <para>Install locale related .ipkg packages;</para> + <para>Installs locale related .ipkg packages;</para> </listitem> <listitem> - <para>Install the list of requested <command>.ipkg</command> packages, + <para>Installs the list of requested <command>.ipkg</command> packages, <command>${IPKG_INSTALL}</command>;</para> </listitem> @@ -75,12 +74,12 @@ <para>Makes available a set of functions which may be used by callers of the class: <command>zap_root_password</command>, <command>create_etc_timestamp</command> and - <command>remote_init_link</command>;</para> + <command>remove_init_link</command>;</para> </listitem> <listitem> - <para>Adds the rootfs task to run after the do_install task - <command>"addtask rootfs before do_build and + <para>Adds the rootfs task to run after the <emphasis>install</emphasis> + task <command>"addtask rootfs before do_build and do_install"</command>.</para> </listitem> </orderedlist> @@ -204,9 +203,9 @@ </variablelist> <para>Note that the entire process is run under the control of <xref - linkend="fakeroot" /> in order to handle device files, uid and gid's. The + linkend="fakeroot" /> in order to handle device files, uids and gids. The <command>ROOTFS_POSTPROCESS_COMMAND</command> is useful due to the fact that - it runs within he same <xref linkend="fakeroot" /> instance as the rest of + it runs within the same <xref linkend="fakeroot" /> instance as the rest of this class.</para> <para>The class also provides a function <command>real_do_rootfs</command> diff --git a/usermanual/reference/fakeroot.xml b/usermanual/reference/fakeroot.xml index 4be5f2ba57..68892fce87 100644 --- a/usermanual/reference/fakeroot.xml +++ b/usermanual/reference/fakeroot.xml @@ -3,12 +3,12 @@ <title>fakeroot (device node handling)</title> <para>The fakeroot program is designed to allow non-root users to perform - actions that normally require root as part of the package generation - process. It is used by <xref linkend="rootfs_ipkg_class" /> the for root - filesystem creation and by <xref linkend="image_ipkg_class" /> for the - creation of filesystem images. Some recipes also use fakeroot to assist with - parts of the package installation (usually) or building that requires root - privileges.</para> + actions that would normally require root privileges as part of the package + generation process. It is used by the <xref linkend="rootfs_ipkg_class" /> + for root filesystem creation and by the <xref linkend="image_ipkg_class" /> + for the creation of filesystem images. Some recipes also use fakeroot to + assist with parts of the package installation (usually) or building where + root privligeses are expected by the package.</para> <para>In particular fakeroot deals with:</para> @@ -28,7 +28,7 @@ <para>First of all we'll look at an example of how the fakeroot process works when used manually.</para> - <para>If we attempt to create a device node as a normal, non-root, user + <para>If we attempt to create a device node as a normal non-root user then the command will fail, telling is that we do not have permission to create device nodes:<screen>~%> mknod hdc b 22 0 mknod: `hdc': Operation not permitted</screen>Yet the <xref @@ -37,7 +37,7 @@ mknod: `hdc': Operation not permitted</screen>Yet the <xref privileges.</para> <para>Let's try and create that node again, this time we'll run the - commands from within the fakeroot process:<screen>~%> ./tmp/staging/x86_64-linux/bin/fakeroot + commands from within a fakeroot process:<screen>~%> ./tmp/staging/x86_64-linux/bin/fakeroot ~#> mknod hdc b 22 0 ~#> ls -l hdc brw------- 1 root root 22, 0 Aug 18 13:20 hdc @@ -59,8 +59,8 @@ mount: only root can do that libfakeroot and about not being able to run mount because we are not root.</para> - <para>If we exit the fakeroot process and then look at the device node we - see this:<screen>~#> exit + <para>If we exit the fakeroot process and then look at the device node + this is what we see:<screen>~#> exit ~%> ls -l hdc brw------- 1 user user 22, 0 Aug 18 13:20 hdc ~#></screen></para> @@ -72,13 +72,13 @@ brw------- 1 user user 22, 0 Aug 18 13:20 hdc <command>LD_PRELOAD</command> to load a shared library into program which replaces calls into libc, such as open and stat, and then returns information to make it look like certain commands succeeded without - actually performing them. So when creating a device node fakeroot - will:</para> + actually performing those commands. So when creating a device node + fakeroot will:</para> <orderedlist> <listitem> <para>Intercept the mknod system call and instead of creating a device - node it'll just created an empty file, owned by the user who run + node it'll just create an empty file, owned by the user who run fakeroot;</para> </listitem> @@ -111,9 +111,9 @@ brw------- 1 user user 22, 0 Aug 18 13:20 hdc </listitem> <listitem> - <para>None of the device nodes, uid or gid's will appear on disk, - however if you for example tar up a directory from within fakeroot all - of these device, uid's and gid's will appear in the tar + <para>None of the device nodes, uids or gids will appear on disk. + However if you tar up a directory from within fakeroot (for example), + all of these device, uids and gids will appear correctly in the tar archive;</para> </listitem> @@ -131,7 +131,7 @@ brw------- 1 user user 22, 0 Aug 18 13:20 hdc <title>Root filesystem, images and fakeroot</title> <para>Many people have been confused by the generated root filesystem not - containing and valid device nodes. But this is the expected + containing any valid device nodes. This is in fact the expected behaviour.</para> <para>When you look at a generated root filesystem you'll notice that the @@ -142,7 +142,7 @@ brw------- 1 user user 22, 0 Aug 18 13:20 hdc ~%></screen>These are empty files and not device nodes at all.</para> <para>If we look in the image files generated from that root filesystem - everything is actually ok:<screen>~%> tar -ztvf tmp/deploy/images/titan-titan-20060816030639.rootfs.tar.gz | grep " ./dev/ttySC" + then everything is actually ok:<screen>~%> tar -ztvf tmp/deploy/images/titan-titan-20060816030639.rootfs.tar.gz | grep " ./dev/ttySC" crw-r----- root/root 204,8 2006-08-16 13:07:12 ./dev/ttySC0 crw-r----- root/root 204,9 2006-08-16 13:07:12 ./dev/ttySC1 crw-r----- root/root 204,10 2006-08-16 13:07:12 ./dev/ttySC2 @@ -162,8 +162,9 @@ crw-r----- root/root 204,10 2006-08-16 13:07:12 ./dev/ttySC2 <para>Some applications require that you have root permissions to run their installation routine, and this is another area where fakeroot can - help. In a recipe a standard task, such as <emphasis>do_install</emphasis> - for example:<screen>do_install() { + help. In a recipe the method for a standard task, such as the + <command>do_install</command> method for the <emphasis>install</emphasis> + task:<screen>do_install() { install -d ${D}${bindir} ${D}${sbindir} ${D}${mandir}/man8 \ ${D}${sysconfdir}/default \ ${D}${sysconfdir}/init.d \ @@ -172,7 +173,7 @@ crw-r----- root/root 204,10 2006-08-16 13:07:12 ./dev/ttySC2 oe_runmake install DESTDIR=${D} oe_runmake install-man DESTDIR=${D} ...</screen>can be modified to run within a fakeroot environment by - prefixing the task with fakeroot:<screen><emphasis role="bold">fakeroot</emphasis> do_install() { + prefixing the method name with fakeroot:<screen><emphasis role="bold">fakeroot</emphasis> do_install() { install -d ${D}${bindir} ${D}${sbindir} ${D}${mandir}/man8 \ ${D}${sysconfdir}/default \ ${D}${sysconfdir}/init.d \ diff --git a/usermanual/reference/image_types.xml b/usermanual/reference/image_types.xml index 4756c248d9..68058bec3e 100644 --- a/usermanual/reference/image_types.xml +++ b/usermanual/reference/image_types.xml @@ -6,31 +6,32 @@ image containing the root filesystem for the target device. There are several variables which can be used to control the type of output images and the settings for those images such as endianess or compression ratios. This - section details the available images and the variable that effect them. See + section details the available images and the variables that effect them. See the <xref linkend="image_ipkg_class" /> section for details on how image generation is configured.</para> <para>The final root file system will consist of all of the files located in - <command>${IMAGE_ROOTFS}</command>, which is usually - <command>tmp/rootfs</command> in your build area. One important difference - between the image and the root file system directory is that any files which - can only be created by privileged users, such as device nodes, will not - appear in the <command>${IMAGE_ROOTFS}</command> directory but they will be - present in any images that are generated. This is due to - <emphasis>fakeroot</emphasis> system keeping track of these special files - and making them available when generating the image even though they are not - appear in the root filesystem directory. For this reason it is important to - always create an actual image to use for testing, even if it's just a .tar - archive, to ensure you have the correct device nodes and any other special - files.</para> + image root filesystem directory, <command>${IMAGE_ROOTFS}</command>, which + is usually <command>tmp/rootfs</command> in the build area. One important + difference between the images and the root file system directory is that any + files which can only be created by privileged users, such as device nodes, + will not appear in the <command>${IMAGE_ROOTFS}</command> directory but they + will be present in any images that are generated. This is due to + <emphasis><xref linkend="fakeroot" /> </emphasis>system keeping track of + these special files and making them available when generating the image - + even though they do not appear in the root filesystem directory. For this + reason it is important to always create an actual image to use for testing, + even if it's just a <command>.tar</command> archive, to ensure you have the + correct device nodes and any other special files.</para> <section> <title>Defining images</title> - <para>Each supported image type is defined via a set of variables with the - name of the image type appended. The behaviour of the built in image types - can be changed by modifying these variables, and new types created by - defining these variables for the new type.</para> + <para>Each supported image type is defined via a set of variables. Each + variables has the name of the image type appended to indicate the settings + for that particular image type. The behaviour of the built in image types + can be changed by modifying these variables, and new types can be created + by defining these variables for the new type.</para> <para>The variables that define an image type are:</para> @@ -39,8 +40,8 @@ <term>IMAGE_CMD_<type></term> <listitem> - <para>Specifies the command that is run to generate an image of the - specified type.</para> + <para>Specifies the actual command that is run to generate an image + of the specified type.</para> </listitem> </varlistentry> @@ -49,11 +50,11 @@ <listitem> <para>Used to pass additional command line arguments to the - <command>IMAGE_CMD</command> without needing to redefine the entire + <command>IMAGE_CMD</command> without the need to redefine the entire image command. This is often used to pass options such as endianess and compression rations. You need to look at the - <command>IMAGE_CMD</command> to determine which command these - options are being passed to.</para> + <command>IMAGE_CMD</command> definition to determine how these + options are being used.</para> </listitem> </varlistentry> @@ -82,7 +83,7 @@ <section> <title>Available image types</title> - <para>The following image types are built in to openembedded:</para> + <para>The following image types are built in to OpenEmbedded:</para> <variablelist> <varlistentry> @@ -114,7 +115,7 @@ system"</emphasis> images. This is a read only compressed filesystem which is used directly by decompressing files into RAM as they are accessed. Files sizes are limited to 16MB, file system size is - limited to 256MB, only 8-bit uid and guids are support, no hard + limited to 256MB, only 8-bit uids and gids are supported, no hard links are supported and no time stamps are supported.<screen>IMAGE_CMD_cramfs = "mkcramfs ${IMAGE_ROOTFS} \ ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cramfs \ ${EXTRA_IMAGECMD}"</screen></para> @@ -180,7 +181,7 @@ rmdir ${DEPLOY_DIR_IMAGE}/tmp.gz"</screen></para> <para>Creates a squashfs image. This is a read only compressed filesystem which is used directly with files uncompressed into RAM as they are accessed. Files and filesystems may be up to 2^64 bytes - in size, full 32-bit uid and gids are stored, it detects duplicate + in size, full 32-bit uids and gids are stored, it detects duplicate files and stores only a single copy, all meta-data is compressed and big and little endian filesystems can be mounted on any platform.</para> diff --git a/usermanual/reference/var_src_uri.xml b/usermanual/reference/var_src_uri.xml index 29136681d0..47778fa483 100644 --- a/usermanual/reference/var_src_uri.xml +++ b/usermanual/reference/var_src_uri.xml @@ -34,7 +34,7 @@ tag/value pairs of the form <command>"a=b"</command> and are semi-colon separated from each other and from the URI. The follow examples shows two options being included, the patch and pnum options:<screen>file://ospfd-no-opaque-lsa-fix.patch;patch=1;pnum=2</screen>The - supported methods for fetching source and files is:</para> + supported methods for fetching source and files are:</para> <variablelist> <varlistentry> @@ -42,7 +42,7 @@ <listitem> <para>Used to download files and source code via the specified URL. - These types are fetched from the specified location using wget.</para> + These are fetched from the specified location using wget.</para> </listitem> </varlistentry> @@ -85,8 +85,8 @@ <para>When source code is specified as a part of <command>SRC_URI</command> it is unpacked into the work directory, <command>${WORKDIR}</command>. The unpacker recognises several archive and compression types and for these it - will extract all of the files from the archive into the work directory. The - supported types are:</para> + will decompress any compressed files and extract all of the files from + archives into the work directory. The supported types are:</para> <variablelist> <varlistentry> @@ -197,8 +197,8 @@ <section> <title>file: for patches and additional files</title> - <para>The file URI's are used to copy files included as part of the - package meta data into the work directory to be used when building the + <para>The file URI's are used to copy files, included as part of the + package meta data, into the work directory to be used when building the package. Typical use of the file URI's is to specify patches that be applied to the source and to provide additional files, such as init scripts, to be included in the final package.</para> @@ -216,10 +216,10 @@ <para>The following example shows the specification of a non-patch file. In this case it's an init script:<screen>file://quagga.init</screen>Non-patch files are copied to the work directory, <command>${WORKDIR}</command>. You - can access these files from with a recipe by referring to them relative to - the work directory. The following example from quagga show the above init - script being included in the package by copying it during the install - task:<screen>do_install () { + can access these files from within a recipe by referring to them relative + to the work directory. The following example, from the quagga recipe, + shows the above init script being included in the package by copying it + during the <emphasis>install</emphasis> task:<screen>do_install () { # Install init script and default settings install -m 0755 -d ${D}${sysconfdir}/default ${D}${sysconfdir}/init.d ${D}${sysconfdir}/quagga install -m 0644 <emphasis role="bold">${WORKDIR}/quagga.init</emphasis> ${D}${sysconfdir}/init.d/quagga @@ -246,7 +246,7 @@ <para>By default patches are applied with the <command>"-p 1"</command> parameter, which strips off the first directory of the pathname in the patches. This option is used to explicitly control - value passed to <command>"-p"</command>. The most typical use is + the value passed to <command>"-p"</command>. The most typical use is when the patches are relative to the source directory already and need to be applied using <command>"-p 0"</command>, in which case the <command>"pnum=0"</command> option is supplied.</para> @@ -264,7 +264,7 @@ the <emphasis>date=</emphasis> to specify a checkout for specified date. It is preferable to use either a <emphasis>date=</emphasis> or a <emphasis>tag=</emphasis> option to select a specific date and/or tag from - cvs rather than leave the checkout floating at the head revision. </para> + cvs rather than leave the checkout floating at the head revision.</para> <para>Supported options:</para> @@ -351,7 +351,7 @@ <title>svn</title> <para>The svn fetcher is used to retrieve files from a subversion - repository. </para> + repository.</para> <para><screen> svn://svn.xiph.org/trunk;module=Tremor;rev=4573;proto=http</screen></para> @@ -570,7 +570,7 @@ export DEBIAN_MIRROR = "http://mirror.optusnet.com.au/debian/pool" export SOURCEFORGE_MIRROR = "http://optusnet.dl.sourceforge.net/sourceforge"</screen></para> <para>Mirrors can be extended in individual recipes via the use of - <command>MIRRORS_prepend</command> or <command>MIRROR_append</command>. + <command>MIRRORS_prepend</command> or <command>MIRRORS_append</command>. Each entry in the list contains the mirror name on the left-hand side and the URI of the mirror on the right-hand side. The following example from libffi shows the addition of two URI for the @@ -585,13 +585,14 @@ export SOURCEFORGE_MIRROR = "http://optusnet.dl.sourceforge.net/sourceforge"</sc <para>Sometimes it is desirable to only include patches for a specific architecture and/or to include different files based on the architecture. - This can be done via the SRC_URI_append and/or SRC_URI_prepend methods for - adding additional URI's based on the architecture or machine name.</para> + This can be done via the <command>SRC_URI_append</command> and/or + <command>SRC_URI_prepend</command> methods for adding additional URI's + based on the architecture or machine name.</para> <para>In this example from glibc, the patch creates a configuration file for glibc, which should only be used or the sh4 architecture. Therefore - this patch is appended to the SRC_URI, but only for the sh4 architecture. - For other architectures it is ignored:<screen># Build fails on sh4 unless no-z-defs is defined + this patch is appended to the <command>SRC_URI</command>, but only for the + sh4 architecture. For other architectures it is ignored:<screen># Build fails on sh4 unless no-z-defs is defined SRC_URI_append_sh4 = " file://no-z-defs.patch;patch=1"</screen></para> </section> @@ -600,15 +601,16 @@ SRC_URI_append_sh4 = " file://no-z-defs.patch;patch=1"</screen></para> <para>In order to obtain a set of source files for a build you can use the <emphasis>src_distribute_local</emphasis> class. This will result in all - the files that were actually used during a build to be made available and - therefore they can be distributed with the binaries.</para> + the files that were actually used during a build being made available in a + seperate directory and therefore they can be distributed with the + binaries.</para> - <para>Enabling this option is as simply as activating the functionality by - included the required class in one of your configuration files:<screen>SRC_DIST_LOCAL = "copy" + <para>Enabling this option is as simple as activating the functionality by + including the required class in one of your configuration files:<screen>SRC_DIST_LOCAL = "copy" INHERIT += "src_distribute_local"</screen></para> <para>Now during a build each recipe which has a LICENSE that mandates - source availability, like the GPL ,will be placed into the source + source availability, like the GPL, will be placed into the source distribution directory, <command>${SRC_DISTRIBUTEDIR}</command>, after building.</para> |