mirror of
https://git.yoctoproject.org/poky
synced 2026-05-30 12:29:55 +00:00
bitbake: user-manual-fetching.xml: Re-write of "File Download Support" chapter.
Basic re-write to clean up text and flow. (Bitbake rev: 0f82dc4c22ce015bef87fd5aae0b6fa3e429016e) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
committed by
Richard Purdie
parent
b4b3bf56f6
commit
f3caa2b27e
@@ -2,84 +2,110 @@
|
|||||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||||||
|
|
||||||
<chapter>
|
<chapter>
|
||||||
<title>File download support</title>
|
<title>File Download Support</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
BitBake's <filename>fetch</filename> and
|
||||||
|
<filename>fetch2</filename> modules support downloading
|
||||||
|
files.
|
||||||
|
This chapter provides an overview of the fetching process
|
||||||
|
and also presents sections on each of the fetchers BitBake
|
||||||
|
supports.
|
||||||
|
<note>
|
||||||
|
The original <filename>fetch</filename> code, for all
|
||||||
|
practical purposes, has been replaced by
|
||||||
|
<filename>fetch2</filename> code.
|
||||||
|
Consequently, the information in this chapter does not
|
||||||
|
apply to <filename>fetch</filename>.
|
||||||
|
</note>
|
||||||
|
</para>
|
||||||
|
|
||||||
<section id='file-download-overview'>
|
<section id='file-download-overview'>
|
||||||
<title>Overview</title>
|
<title>Overview</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake provides support to download files.
|
When BitBake starts to execute, the very first thing
|
||||||
This procedure is called fetching and is handled by the
|
it does is to fetch the source files needed.
|
||||||
fetch and fetch2 modules.
|
This section overviews the process.
|
||||||
At this point, the original fetch code is considered to
|
For some additional information on fetching source files, see the
|
||||||
be replaced by fetch2 and this manual is only related
|
"<link linkend='source-fetching-dev-environment'>Source Fetching</link>"
|
||||||
to the fetch2 codebase.
|
section.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <filename>SRC_URI</filename> is normally used to
|
When BitBake goes looking for source files, it follows a search
|
||||||
tell BitBake which files to fetch.
|
order:
|
||||||
The next sections describe the available fetchers and
|
<orderedlist>
|
||||||
their options.
|
<listitem><para><emphasis>Pre-mirror Sites:</emphasis>
|
||||||
Each fetcher honors a set of variables and per
|
BitBake first uses pre-mirrors to try and find source
|
||||||
URI parameters separated by a “;” consisting of a key and
|
files.
|
||||||
a value.
|
These locations are defined using the
|
||||||
The semantics of the variables and parameters are
|
<link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
|
||||||
defined by the fetcher.
|
variable.
|
||||||
BitBake tries to have consistent semantics between the
|
</para></listitem>
|
||||||
different fetchers.
|
<listitem><para><emphasis>Source URI:</emphasis>
|
||||||
|
If pre-mirrors fail, BitBake uses
|
||||||
|
<link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para><emphasis>Mirror Sites:</emphasis>
|
||||||
|
If fetch failures occur using <filename>SRC_URI</filename>,
|
||||||
|
BitBake next uses mirror location as defined by the
|
||||||
|
<link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
|
||||||
|
variable.
|
||||||
|
</para></listitem>
|
||||||
|
</orderedlist>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The overall fetch process first attempts to fetch from
|
|
||||||
<filename>PREMIRRORS</filename>.
|
|
||||||
If these fail, the original <filename>SRC_URI</filename>
|
|
||||||
is attempted.
|
|
||||||
If that fails, BitBake falls back to
|
|
||||||
<filename>MIRRORS</filename>.
|
|
||||||
Because cross-URLs are supported, it is possible to mirror
|
Because cross-URLs are supported, it is possible to mirror
|
||||||
a Git repository on an HTTP server as a tarball.
|
a Git repository on an HTTP server as a tarball.
|
||||||
Here are some examples that show commonly used mirror
|
Here are some examples that show commonly used mirror
|
||||||
definitions:
|
definitions:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
PREMIRRORS ?= "\
|
PREMIRRORS ?= "\
|
||||||
bzr://.*/.* http://somemirror.org/sources/ \n \
|
bzr://.*/.* http://somemirror.org/sources/ \n \
|
||||||
cvs://.*/.* http://somemirror.org/sources/ \n \
|
cvs://.*/.* http://somemirror.org/sources/ \n \
|
||||||
git://.*/.* http://somemirror.org/sources/ \n \
|
git://.*/.* http://somemirror.org/sources/ \n \
|
||||||
hg://.*/.* http://somemirror.org/sources/ \n \
|
hg://.*/.* http://somemirror.org/sources/ \n \
|
||||||
osc://.*/.* http://somemirror.org/sources/ \n \
|
osc://.*/.* http://somemirror.org/sources/ \n \
|
||||||
p4://.*/.* http://somemirror.org/sources/ \n \
|
p4://.*/.* http://somemirror.org/sources/ \n \
|
||||||
svk://.*/.* http://somemirror.org/sources/ \n \
|
svk://.*/.* http://somemirror.org/sources/ \n \
|
||||||
svn://.*/.* http://somemirror.org/sources/ \n"
|
svn://.*/.* http://somemirror.org/sources/ \n"
|
||||||
|
|
||||||
MIRRORS =+ "\
|
MIRRORS =+ "\
|
||||||
ftp://.*/.* http://somemirror.org/sources/ \n \
|
ftp://.*/.* http://somemirror.org/sources/ \n \
|
||||||
http://.*/.* http://somemirror.org/sources/ \n \
|
http://.*/.* http://somemirror.org/sources/ \n \
|
||||||
https://.*/.* http://somemirror.org/sources/ \n"
|
https://.*/.* http://somemirror.org/sources/ \n"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Non-local downloaded output is placed
|
Any source files that are not local (i.e. downloaded from
|
||||||
into the directory specified by the
|
the Internet) are placed into the download directory,
|
||||||
<filename>DL_DIR</filename> variable.
|
which is specified by
|
||||||
For non local archive downloads, the code can verify
|
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>.
|
||||||
sha256 and md5 checksums for the download to ensure
|
</para>
|
||||||
the file has been downloaded correctly.
|
|
||||||
These can be specified in the following forms
|
<para>
|
||||||
for md5 and sha256 checksums, respectively:
|
For non-local archive downloads, the fetcher code can verify
|
||||||
|
sha256 and md5 checksums to ensure
|
||||||
|
the archives have been downloaded correctly.
|
||||||
|
You can specify these checksums by using the
|
||||||
|
<filename>SRC_URI</filename> variable with the appropriate
|
||||||
|
varflags as follows:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
SRC_URI[md5sum]
|
SRC_URI[md5sum]
|
||||||
SRC_URI[sha256sum]
|
SRC_URI[sha256sum]
|
||||||
</literallayout>
|
</literallayout>
|
||||||
You can also specify them as parameters on the
|
You can also specify the checksums as parameters on the
|
||||||
<filename>SRC_URI</filename>:
|
<filename>SRC_URI</filename> as shown below:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
SRC_URI="http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
|
SRC_URI="http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
If <filename>BB_STRICT_CHECKSUM</filename> is set, any download
|
If
|
||||||
without a checksum will trigger an error message.
|
<link linkend='var-BB_STRICT_CHECKSUM'><filename>BB_STRICT_CHECKSUM</filename></link>
|
||||||
In cases where multiple files are listed in
|
is set, any download without a checksum triggers an error message.
|
||||||
|
In cases where multiple files are listed using
|
||||||
<filename>SRC_URI</filename>, the name parameter is used
|
<filename>SRC_URI</filename>, the name parameter is used
|
||||||
assign names to the URLs and these are then specified
|
assign names to the URLs and these are then specified
|
||||||
in the checksums using the following form:
|
in the checksums using the following form:
|
||||||
@@ -89,142 +115,226 @@ MIRRORS =+ "\
|
|||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='local-file-fetcher'>
|
<section id='bb-fetchers'>
|
||||||
<title>Local file fetcher</title>
|
<title>Fetchers</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The URN for the local file fetcher is file.
|
As mentioned in the previous section, the
|
||||||
The filename can be either absolute or relative.
|
<filename>SRC_URI</filename> is normally used to
|
||||||
If the filename is relative,
|
tell BitBake which files to fetch.
|
||||||
<filename>FILESPATH</filename> and failing that
|
And, the fetcher BitBake uses depends on the how
|
||||||
<filename>FILESDIR</filename> will be used to find the
|
<filename>SRC_URI</filename> is set.
|
||||||
appropriate relative file.
|
</para>
|
||||||
The metadata usually extend these variables to include
|
|
||||||
variations of the values in <filename>OVERRIDES</filename>.
|
<para>
|
||||||
Single files and complete directories can be specified.
|
These next few sections describe the available fetchers and
|
||||||
<literallayout class='monospaced'>
|
their options.
|
||||||
|
Each fetcher honors a set of variables URI parameters,
|
||||||
|
which are separated by semi-colon characters and consist
|
||||||
|
of a key and a value.
|
||||||
|
The semantics of the variables and parameters are
|
||||||
|
defined by the fetcher.
|
||||||
|
BitBake tries to have consistent semantics between the
|
||||||
|
different fetchers.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<section id='local-file-fetcher'>
|
||||||
|
<title>Local file fetcher</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The URN for the local file fetcher is file.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The filename can be either absolute or relative.
|
||||||
|
If the filename is relative,
|
||||||
|
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
|
||||||
|
is used.
|
||||||
|
Failing that,
|
||||||
|
<link linkend='var-FILESDIR'><filename>FILESDIR</filename></link>
|
||||||
|
is used to find the appropriate relative file.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The metadata usually extend these variables to include
|
||||||
|
variations of the values in
|
||||||
|
<link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>.
|
||||||
|
Single files and complete directories can be specified.
|
||||||
|
<literallayout class='monospaced'>
|
||||||
SRC_URI = "file://relativefile.patch"
|
SRC_URI = "file://relativefile.patch"
|
||||||
SRC_URI = "file://relativefile.patch;this=ignored"
|
SRC_URI = "file://relativefile.patch;this=ignored"
|
||||||
SRC_URI = "file:///Users/ich/very_important_software"
|
SRC_URI = "file:///Users/ich/very_important_software"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='cvs-fetcher'>
|
<section id='cvs-fetcher'>
|
||||||
<title>CVS fetcher</title>
|
<title>CVS fetcher</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The URN for the CVS fetcher is cvs.
|
The URN for the CVS fetcher is cvs.
|
||||||
This fetcher honors the variables <filename>CVSDIR</filename>,
|
</para>
|
||||||
<filename>SRCDATE</filename>, <filename>FETCHCOMMAND_cvs</filename>,
|
|
||||||
<filename>UPDATECOMMAND_cvs</filename>.
|
|
||||||
<filename>DL_DIR</filename> specifies where a
|
|
||||||
temporary checkout is saved.
|
|
||||||
<filename>SRCDATE</filename> specifies which date to
|
|
||||||
use when doing the fetching (the special value of "now"
|
|
||||||
will cause the checkout to be updated on every build).
|
|
||||||
<filename>FETCHCOMMAND</filename> and
|
|
||||||
<filename>UPDATECOMMAND</filename> specify which executables
|
|
||||||
to use for the CVS checkout or update.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The supported parameters are module, tag, date,
|
This fetcher honors the variables <filename>CVSDIR</filename>,
|
||||||
method, localdir, rshand scmdata.
|
<filename>SRCDATE</filename>, <filename>FETCHCOMMAND_cvs</filename>,
|
||||||
The module specifies which module to check out,
|
<filename>UPDATECOMMAND_cvs</filename>.
|
||||||
the tag describes which CVS TAG should be used for
|
The
|
||||||
the checkout.
|
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
|
||||||
By default, the TAG is empty.
|
variable specifies where a
|
||||||
A date can be specified to override the
|
temporary checkout is saved.
|
||||||
<filename>SRCDATE</filename> of the
|
The
|
||||||
configuration to checkout a specific date.
|
<link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
|
||||||
The special value of "now" will cause the checkout to be
|
variable specifies which date to
|
||||||
updated on every build.
|
use when doing the fetching.
|
||||||
method is by default pserver.
|
The special value of "now" causes the checkout to be
|
||||||
If ext is used the rsh parameter will be evaluated
|
updated on every build.
|
||||||
and <filename>CVS_RSH</filename> will be set.
|
The <filename>FETCHCOMMAND</filename> and
|
||||||
Finally, localdir is used to checkout into a special
|
<filename>UPDATECOMMAND</filename> variables specify the executables
|
||||||
directory relative to <filename>CVSDIR</filename>.
|
to use for the CVS checkout or update.
|
||||||
<literallayout class='monospaced'>
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The supported parameters are as follows:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem><para><emphasis>"module":</emphasis>
|
||||||
|
Specifies the module to check out.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para><emphasis>"tag":</emphasis>
|
||||||
|
Describes which CVS TAG should be used for
|
||||||
|
the checkout.
|
||||||
|
By default, the TAG is empty.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para><emphasis>"date":</emphasis>
|
||||||
|
Specifies a date.
|
||||||
|
If no "date" is specified, the
|
||||||
|
<link linkend='var-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.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para><emphasis>"method":</emphasis>
|
||||||
|
By default <filename>pserver</filename>.
|
||||||
|
If "method" is set to "ext", BitBake examines the "rsh"
|
||||||
|
parameter and sets <filename>CVS_RSH</filename>.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para><emphasis>"localdir":</emphasis>
|
||||||
|
Used to checkout force into a special
|
||||||
|
directory relative to <filename>CVSDIR</filename>.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para><emphasis>"rsh"</emphasis>
|
||||||
|
Used in conjunction with the "method" parameter.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para><emphasis>"scmdata":</emphasis>
|
||||||
|
I need a description for this.
|
||||||
|
</para></listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
Following are two examples using cvs:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
|
SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
|
||||||
SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
|
SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='http-ftp-fetcher'>
|
<section id='http-ftp-fetcher'>
|
||||||
<title>HTTP/FTP fetcher</title>
|
<title>HTTP/FTP fetcher</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The URNs for the HTTP/FTP fetcher are http, https, and ftp.
|
The URNs for the HTTP/FTP fetcher are http, https, and ftp.
|
||||||
This fetcher honors the variables
|
</para>
|
||||||
<filename>FETCHCOMMAND_wget</filename>.
|
|
||||||
<filename>FETCHCOMMAND</filename> contains the command used
|
<para>
|
||||||
for fetching.
|
This fetcher honors the variables
|
||||||
“${URI}” and “${FILES}” will be replaced by the URI and
|
<filename>FETCHCOMMAND_wget</filename>.
|
||||||
basename of the file to be fetched.
|
The <filename>FETCHCOMMAND</filename> variable
|
||||||
<literallayout class='monospaced'>
|
contains the command used for fetching.
|
||||||
|
“${URI}” and “${FILES}” are replaced by the URI and
|
||||||
|
the base name of the file to be fetched.
|
||||||
|
<literallayout class='monospaced'>
|
||||||
SRC_URI = "http://oe.handhelds.org/not_there.aac"
|
SRC_URI = "http://oe.handhelds.org/not_there.aac"
|
||||||
SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
|
SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
|
||||||
SRC_URI = "ftp://you@oe.handheld.sorg/home/you/secret.plan"
|
SRC_URI = "ftp://you@oe.handheld.sorg/home/you/secret.plan"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='svn-fetcher'>
|
<section id='svn-fetcher'>
|
||||||
<title>SVN Fetcher</title>
|
<title>SVN Fetcher</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The URN for the SVN fetcher is svn.
|
The URN for the SVN fetcher is svn.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This fetcher honors the variables
|
This fetcher honors the variables
|
||||||
<filename>FETCHCOMMAND_svn</filename>,
|
<filename>FETCHCOMMAND_svn</filename>,
|
||||||
<filename>SVNDIR</filename>,
|
<filename>SVNDIR</filename>,
|
||||||
and <filename>SRCREV</filename>.
|
and
|
||||||
<filename>FETCHCOMMAND</filename> contains the
|
<link linkend='var-SRCREV'><filename>SRCREV</filename></link>.
|
||||||
subversion command.
|
The <filename>FETCHCOMMAND</filename> variable contains the
|
||||||
<filename>SRCREV</filename> specifies which revision
|
<filename>subversion</filename> command.
|
||||||
to use when doing the fetching.
|
The <filename>SRCREV</filename> variable specifies which revision
|
||||||
</para>
|
to use when doing the fetching.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The supported parameters are proto, rev and scmdata.
|
The supported parameters are as follows:
|
||||||
proto is the Subversion protocol, rev is the
|
<itemizedlist>
|
||||||
Subversion revision.
|
<listitem><para><emphasis>"proto":</emphasis>
|
||||||
If scmdata is set to “keep”, the “.svn” directories will
|
The Subversion protocol.
|
||||||
be available during compile-time.
|
</para></listitem>
|
||||||
<literallayout class='monospaced'>
|
<listitem><para><emphasis>"rev":</emphasis>
|
||||||
|
The Subversion revision.
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para><emphasis>"scmdata":</emphasis>
|
||||||
|
Set to "keep" causes the “.svn” directories
|
||||||
|
to be available during compile-time.
|
||||||
|
</para></listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
Following are two examples using svn:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
SRC_URI = "svn://svn.oe.handhelds.org/svn;module=vip;proto=http;rev=667"
|
SRC_URI = "svn://svn.oe.handhelds.org/svn;module=vip;proto=http;rev=667"
|
||||||
SRC_URI = "svn://svn.oe.handhelds.org/svn/;module=opie;proto=svn+ssh;date=20060126"
|
SRC_URI = "svn://svn.oe.handhelds.org/svn/;module=opie;proto=svn+ssh;date=20060126"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='git-fetcher'>
|
<section id='git-fetcher'>
|
||||||
<title>GIT Fetcher</title>
|
<title>GIT Fetcher</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The URN for the GIT Fetcher is git.
|
The URN for the Git Fetcher is git.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The variable <filename>GITDIR</filename> will be used as the
|
The variable <filename>GITDIR</filename> is used as the
|
||||||
base directory where the Git tree is cloned to.
|
base directory in which the Git tree is cloned.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The parameters are tag, protocol, and scmdata.
|
The supported parameters are as follows:
|
||||||
The tag parameter is a Git tag, the default is “master”.
|
<itemizedlist>
|
||||||
The protocol tag is the Git protocol to use and defaults to “git”
|
<listitem><para><emphasis>"tag":</emphasis>
|
||||||
if a hostname is set, otherwise it is “file”.
|
The Git tag.
|
||||||
If scmdata is set to “keep”, the “.git” directory will be available
|
The default is "master".
|
||||||
during compile-time.
|
</para></listitem>
|
||||||
<literallayout class='monospaced'>
|
<listitem><para><emphasis>"protocol":</emphasis>
|
||||||
|
The Git protocol.
|
||||||
|
The default is "git" when a hostname is set.
|
||||||
|
If a hostname is not set, the Git protocol is "file".
|
||||||
|
</para></listitem>
|
||||||
|
<listitem><para><emphasis>"scmdata":</emphasis>
|
||||||
|
When set to “keep”, the “.git” directory is available
|
||||||
|
during compile-time.
|
||||||
|
</para></listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
Following are two examples using git:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
|
SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
|
||||||
SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"
|
SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
</para>
|
</para>
|
||||||
|
</section>
|
||||||
</section>
|
</section>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|||||||
Reference in New Issue
Block a user