diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/user-manual/user-manual-bitbakecommand.xml | 60 |
1 files changed, 30 insertions, 30 deletions
diff --git a/doc/user-manual/user-manual-bitbakecommand.xml b/doc/user-manual/user-manual-bitbakecommand.xml index 361b4f078..08a37a986 100644 --- a/doc/user-manual/user-manual-bitbakecommand.xml +++ b/doc/user-manual/user-manual-bitbakecommand.xml @@ -54,7 +54,7 @@ <title>Executing a task against a single .bb</title> <para>Executing tasks for a single file is relatively simple. You specify the file in question, and BitBake - parses it and executes the specified task (or + parses it and executes the specified task (or <quote>build</quote>by default). It obeys intertask dependencies when doing so.</para> <para> @@ -88,7 +88,7 @@ <para>The next section, Metadata, outlines how to specify such things.</para> <para>Note that the bitbake command, when not using - --buildfile, accepts a + --buildfile, accepts a <varname>PROVIDER</varname>, not a filename or anything else. By default, a .bb generally PROVIDES its packagename, packagename-version, and @@ -111,17 +111,17 @@ <title>Generating dependency graphs</title> <para>BitBake is able to generate dependency graphs using the dot syntax. These graphs can be converted to images - using the - <application>dot</application>application from + using the + <application>dot</application>application from <ulink url="http://www.graphviz.org">Graphviz</ulink>. Two - files will be written into the current working directory, + files will be written into the current working directory, <emphasis>depends.dot</emphasis>containing dependency - information at the package level and + information at the package level and <emphasis>task-depends.dot</emphasis>containing a breakdown of the dependencies at the task level. To stop depending on - common depends, one can use the + common depends, one can use the <prompt>-I depend</prompt>to omit these from the graph. - This can lead to more readable graphs. This way, + This can lead to more readable graphs. This way, <varname>DEPENDS</varname>from inherited classes such as base.bbclass can be removed from the graph.</para> <screen> @@ -146,10 +146,10 @@ <section> <title>Metadata</title> <para>As you may have seen in the usage information, or in the - information about .bb files, the + information about .bb files, the <varname>BBFILES</varname>variable is how the BitBake tool locates its files. This variable is a space separated list of - files that are available, and supports wildcards. + files that are available, and supports wildcards. <example> <title>Setting BBFILES</title> <programlisting> @@ -157,31 +157,31 @@ "/path/to/bbfiles/*.bb"</programlisting> </example></para> <para>With regard to dependencies, it expects the .bb to define - a + a <varname>DEPENDS</varname>variable, which contains a space - separated list of - <quote>package names</quote>, which themselves are the - <varname>PN</varname>variable. The + separated list of + <quote>package names</quote>, which themselves are the + <varname>PN</varname>variable. The <varname>PN</varname>variable is, in general, set to a component of the .bb filename by default.</para> <example> <title>Depending on another .bb</title> - <para>a.bb: + <para>a.bb: <screen>PN = "package-a" DEPENDS += "package-b"</screen></para> - <para>b.bb: + <para>b.bb: <screen>PN = "package-b"</screen></para> </example> <example> <title>Using PROVIDES</title> - <para>This example shows the usage of the + <para>This example shows the usage of the <varname>PROVIDES</varname>variable, which allows a given .bb to specify what functionality it provides.</para> - <para>package1.bb: + <para>package1.bb: <screen>PROVIDES += "virtual/package"</screen></para> - <para>package2.bb: + <para>package2.bb: <screen>DEPENDS += "virtual/package"</screen></para> - <para>package3.bb: + <para>package3.bb: <screen>PROVIDES += "virtual/package"</screen></para> <para>As you can see, we have two different .bb's that provide the same functionality (virtual/package). Clearly, @@ -189,35 +189,35 @@ control which of those providers gets used. There is, indeed, such a way.</para> <para>The following would go into a .conf file, to select - package1: + package1: <screen>PREFERRED_PROVIDER_virtual/package = "package1"</screen></para> </example> <example> <title>Specifying version preference</title> - <para>When there are multiple + <para>When there are multiple <quote>versions</quote>of a given package, BitBake defaults to selecting the most recent version, unless otherwise - specified. If the .bb in question has a + specified. If the .bb in question has a <varname>DEFAULT_PREFERENCE</varname>set lower than the other .bb's (default is 0), then it will not be selected. This allows the person or persons maintaining the repository of .bb files to specify their preference for the default selected version. In addition, the user can specify their preferred version.</para> - <para>If the first .bb is named - <filename>a_1.1.bb</filename>, then the - <varname>PN</varname>variable will be set to - <quote>a</quote>, and the + <para>If the first .bb is named + <filename>a_1.1.bb</filename>, then the + <varname>PN</varname>variable will be set to + <quote>a</quote>, and the <varname>PV</varname>variable will be set to 1.1.</para> - <para>If we then have an + <para>If we then have an <filename>a_1.2.bb</filename>, BitBake will choose 1.2 by default. However, if we define the following variable in a - .conf that BitBake parses, we can change that. + .conf that BitBake parses, we can change that. <screen>PREFERRED_VERSION_a = "1.1"</screen></para> </example> <example> - <title>Using + <title>Using <quote>bbfile collections</quote></title> <para>bbfile collections exist to allow the user to have multiple repositories of bbfiles that contain the same exact |