diff options
author | Scott Rifenbark <srifenbark@gmail.com> | 2018-12-26 16:22:32 -0800 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2018-12-27 13:08:25 +0000 |
commit | fb6de2057aae3fbdf37f007d2e47794b332020e1 (patch) | |
tree | f224e29779ddda2b46d8375efe225e2b281f241f /doc/bitbake-user-manual/bitbake-user-manual-fetching.xml | |
parent | 02845a561b38658ac3edf5cc9c34625ed860d34f (diff) | |
download | bitbake-contrib-fb6de2057aae3fbdf37f007d2e47794b332020e1.tar.gz |
bitbake-user-manual: Created unique tags for glossary variables.
Fixes [YOCTO #12399]
The bug was to get the BitBake User Manual into the YP Mega-manual.
All the changes here create unique tags used with variables in the
BitBake Manual. Prior to the fix, tags were identical between like
variables in the YP reference manual and the BitBake User Manual.
The reason for this is because when I created the BitBake manual's
glossary, it was a cut-and-paste operation to get the bulk of
the work started. At the time, the BitBake User Manual was not
a part of the Mega-manual. Once we decided to include the
BitBake User Manual as part of the Mega-Manual, building the
mega-manual produced warnings for all these duplicate links.
To fix, I have updated the variable tags in the BitBake User
Manual to use the following form:
'var-bb-<variable_name>'
The tags used in the YP ref-manual follow this form (original):
'var-<variable_name>'
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'doc/bitbake-user-manual/bitbake-user-manual-fetching.xml')
-rw-r--r-- | doc/bitbake-user-manual/bitbake-user-manual-fetching.xml | 48 |
1 files changed, 24 insertions, 24 deletions
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml b/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml index 92b2c3d1b..3acd7c403 100644 --- a/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml +++ b/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml @@ -44,7 +44,7 @@ </literallayout> This code sets up an instance of the fetch class. The instance uses a space-separated list of URLs from the - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> variable and then calls the <filename>download</filename> method to download the files. </para> @@ -78,7 +78,7 @@ <listitem><para><emphasis>Pre-mirror Sites:</emphasis> BitBake first uses pre-mirrors to try and find source files. These locations are defined using the - <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link> + <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link> variable. </para></listitem> <listitem><para><emphasis>Source URI:</emphasis> @@ -88,7 +88,7 @@ <listitem><para><emphasis>Mirror Sites:</emphasis> If fetch failures occur, BitBake next uses mirror locations as defined by the - <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link> + <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link> variable. </para></listitem> </itemizedlist> @@ -144,7 +144,7 @@ Any source files that are not local (i.e. downloaded from the Internet) are placed into the download directory, which is specified by the - <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link> + <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> variable. </para> @@ -184,11 +184,11 @@ <para> If - <link linkend='var-BB_STRICT_CHECKSUM'><filename>BB_STRICT_CHECKSUM</filename></link> + <link linkend='var-bb-BB_STRICT_CHECKSUM'><filename>BB_STRICT_CHECKSUM</filename></link> is set, any download without a checksum triggers an error message. The - <link linkend='var-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link> + <link linkend='var-bb-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link> variable can be used to make any attempted network access a fatal error, which is useful for checking that mirrors are complete as well as other things. @@ -265,11 +265,11 @@ The filename you specify within the URL can be either an absolute or relative path to a file. If the filename is relative, the contents of the - <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> + <link linkend='var-bb-FILESPATH'><filename>FILESPATH</filename></link> variable is used in the same way <filename>PATH</filename> is used to find executables. If the file cannot be found, it is assumed that it is available in - <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link> + <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> by the time the <filename>download()</filename> method is called. </para> @@ -304,7 +304,7 @@ allows the name of the downloaded file to be specified. Specifying the name of the downloaded file is useful for avoiding collisions in - <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link> + <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> when dealing with multiple files that have the same name. </para> @@ -355,7 +355,7 @@ A special value of "now" causes the checkout to be updated on every build. </para></listitem> - <listitem><para><emphasis><link linkend='var-CVSDIR'><filename>CVSDIR</filename></link>:</emphasis> + <listitem><para><emphasis><link linkend='var-bb-CVSDIR'><filename>CVSDIR</filename></link>:</emphasis> Specifies where a temporary checkout is saved. The location is often <filename>DL_DIR/cvs</filename>. </para></listitem> @@ -395,7 +395,7 @@ <listitem><para><emphasis>"date":</emphasis> Specifies a date. If no "date" is specified, the - <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link> + <link linkend='var-bb-SRCDATE'><filename>SRCDATE</filename></link> of the configuration is used to checkout a specific date. The special value of "now" causes the checkout to be updated on every build. @@ -406,7 +406,7 @@ to which the module is unpacked. You are forcing the module into a special directory relative to - <link linkend='var-CVSDIR'><filename>CVSDIR</filename></link>. + <link linkend='var-bb-CVSDIR'><filename>CVSDIR</filename></link>. </para></listitem> <listitem><para><emphasis>"rsh"</emphasis> Used in conjunction with the "method" parameter. @@ -448,7 +448,7 @@ <filename>FETCHCMD_svn</filename>, which defaults to "svn". The fetcher's temporary working directory is set by - <link linkend='var-SVNDIR'><filename>SVNDIR</filename></link>, + <link linkend='var-bb-SVNDIR'><filename>SVNDIR</filename></link>, which is usually <filename>DL_DIR/svn</filename>. </para> @@ -509,7 +509,7 @@ source control system. The fetcher works by creating a bare clone of the remote into - <link linkend='var-GITDIR'><filename>GITDIR</filename></link>, + <link linkend='var-bb-GITDIR'><filename>GITDIR</filename></link>, which is usually <filename>DL_DIR/git2</filename>. This bare clone is then cloned into the work directory during the unpack stage when a specific tree is checked out. @@ -612,7 +612,7 @@ This fetcher submodule inherits from the <link linkend='git-fetcher'>Git fetcher</link> and extends that fetcher's behavior by fetching a repository's submodules. - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> is passed to the Git fetcher as described in the "<link linkend='git-fetcher'>Git Fetcher (<filename>git://</filename>)</link>" section. @@ -647,9 +647,9 @@ <para> To use this fetcher, make sure your recipe has proper - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>, - <link linkend='var-SRCREV'><filename>SRCREV</filename></link>, and - <link linkend='var-PV'><filename>PV</filename></link> settings. + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>, + <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link>, and + <link linkend='var-bb-PV'><filename>PV</filename></link> settings. Here is an example: <literallayout class='monospaced'> SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module" @@ -734,15 +734,15 @@ <filename>FETCHCMD_p4</filename>, which defaults to "p4". The fetcher's temporary working directory is set by - <link linkend='var-P4DIR'><filename>P4DIR</filename></link>, + <link linkend='var-bb-P4DIR'><filename>P4DIR</filename></link>, which defaults to "DL_DIR/p4". </para> <para> To use this fetcher, make sure your recipe has proper - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>, - <link linkend='var-SRCREV'><filename>SRCREV</filename></link>, and - <link linkend='var-PV'><filename>PV</filename></link> values. + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>, + <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link>, and + <link linkend='var-bb-PV'><filename>PV</filename></link> values. The p4 executable is able to use the config file defined by your system's <filename>P4CONFIG</filename> environment variable in order to define the Perforce server URL and port, username, and @@ -793,9 +793,9 @@ <filename>google-repo</filename> source control system. The fetcher works by initiating and syncing sources of the repository into - <link linkend='var-REPODIR'><filename>REPODIR</filename></link>, + <link linkend='var-bb-REPODIR'><filename>REPODIR</filename></link>, which is usually - <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link><filename>/repo</filename>. + <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link><filename>/repo</filename>. </para> <para> |