海珠营销型网站建设,wordpress签到积分商城,wordpress 点点主题,wordpress 内容页插件我们遇到的各种自己不了解的技术或产品时#xff0c;都需要阅读用户手册。用户手册里的内容很多时#xff0c;除了由目录组织文档结构外#xff0c;通常还有有一个词汇表#xff0c;一般作为附录放在文档最后。 通过这个按照字母排序的词汇表#xff0c;可以在对整个文档还…
我们遇到的各种自己不了解的技术或产品时都需要阅读用户手册。用户手册里的内容很多时除了由目录组织文档结构外通常还有有一个词汇表一般作为附录放在文档最后。 通过这个按照字母排序的词汇表可以在对整个文档还不够了解的情况下快速的定位到自己需要的内容。 比如我们打开Yocto的manualWelcome to the Yocto Project Documentation — The Yocto Project ® 4.3.999 documentation
在左侧列表中找到“Reference Manual”点开在展开的列表中继续选择“12 Variables Glossary”上方点击首字母S在下方页面中搜索到SRI_URI。 然后就可以得到关于SRI_URI的有用介绍 See the BitBake manual for the initial description for this variable: SRC_URI. 有关该变量的初始描述请参阅 BitBake 手册 SRC_URI。 所以这个变量是用于BitBake的它会识别和使用这个变量。你在bb脚本中设置这个变量bitbake在构建时使用。 Bitbake关于此变量的说明的链接
5 Variables Glossary — Bitbake dev documentation SRC_URI
源文件列表 - 本地或远程。这个变量告诉 BitBake 在编译时要提取哪些文件以及如何提取。例如如果配方或附加文件需要从互联网上获取一个 tar 包配方或附加文件就会使用 SRC_URI 条目指定该 tar 包。另一方面如果配方或附加文件需要获取一个压缩包、应用两个补丁并包含一个自定义文件则配方或附加文件需要一个 SRC_URI 变量来指定所有这些来源。 The list of source files — local or remote. This variable tells BitBake which bits to pull for the build and how to pull them. For example, if the recipe or append file needs to fetch a single tarball from the Internet, the recipe or append file uses a SRC_URI entry that specifies that tarball. On the other hand, if the recipe or append file needs to fetch a tarball, apply two patches, and include a custom file, the recipe or append file needs an SRC_URI variable that specifies all those sources. 下面的列表解释了可用的 URI 协议。URI 协议高度依赖于特定的 BitBake Fetcher 子模块。根据 BitBake 使用的撷取器会使用不同的 URL 参数。有关所支持的提取器的详细信息请参阅提取器部分。 The following list explains the available URI protocols. URI protocols are highly dependent on particular BitBake Fetcher submodules. Depending on the fetcher BitBake uses, various URL parameters are employed. For specifics on the supported Fetchers, see the Fetchers section. * az://: Fetches files from an Azure Storage account using HTTPS.
* bzr://: Fetches files from a Bazaar revision control repository.
* ccrc://: Fetches files from a ClearCase repository.
* cvs://: Fetches files from a CVS revision control repository.
* file://: Fetches files, which are usually files shipped with the Metadata, from the local machine. The path is relative to the FILESPATH variable. Thus, the build system searches, in order, from the following directories, which are assumed to be a subdirectories of the directory in which the recipe file (.bb) or append file (.bbappend) resides: * ${BPN}: the base recipe name without any special suffix or version numbers. * ${BP} - ${BPN}-${PV}: the base recipe name and version but without any special package name suffix. * files: files within a directory, which is named files and is also alongside the recipe or append file.
* ftp://: Fetches files from the Internet using FTP.
* git://: Fetches files from a Git revision control repository.
* gitsm://: Fetches submodules from a Git revision control repository.
* hg://: Fetches files from a Mercurial (hg) revision control repository.
* http://: Fetches files from the Internet using HTTP.
* https://: Fetches files from the Internet using HTTPS.
* npm://: Fetches JavaScript modules from a registry.
* osc://: Fetches files from an OSC (OpenSUSE Build service) revision control repository.
* p4://: Fetches files from a Perforce (p4) revision control repository.
* repo://: Fetches files from a repo (Git) repository.
* ssh://: Fetches files from a secure shell.
* svn://: Fetches files from a Subversion (svn) revision control repository. 这里还有一些值得一提的选项
Here are some additional options worth mentioning: downloadfilename指定存储下载文件时使用的文件名。 name在 SRC_URI 中指定多个文件或 git 仓库时用于识别与 SRC_URI 校验和或 SRCREV 关联的名称。例如
SRC_URI git://example.com/foo.git;branchmain;namefirst \ git://example.com/bar.git;branchmain;namesecond \ http://example.com/file.tar.gz;namethird SRCREV_first f1d2d2f924e986ac86fdf7b36c94bcdf32beec15
SRCREV_second e242ed3bffccdf271b7fbaf34ed72d089537b42f
SRC_URI[third.sha256sum] 13550350a8681c84c861aac2e5b440161c2b33a3e4f302ac680ca5b686de48de subdir 将文件或提取其内容放入指定的子目录。该选项对于不常见的 tar 包或其他存档文件很有用因为这些存档中的文件可能没预先放在一个子目录中。 subpath 在使用 Git fetcher 时将checkout代码仓库的树状文件结构的一部分。如果不设置subpath也可以在设置S变量时指定使用git代码仓库的某个子目录。 unpack 如果文件是存档格式控制是否解压缩。默认操作是解压文件。1是解压0是不解压。 SRCREV
12 Variables Glossary — The Yocto Project ® 4.3.999 documentation
用于构建软件包的源代码的修订版本。此变量仅适用于 Subversion、Git、Mercurial 和 Bazaar。如果你想构建一个固定的修订版本又想避免每次 BitBake 解析你的配方时都在远程版本库中执行查询你应该指定一个完整修订版本标识符的 SRCREV而不仅仅是一个标签。 The revision of the source code used to build the package. This variable applies only when using Subversion, Git, Mercurial and Bazaar. If you want to build a fixed revision and you want to avoid performing a query on the remote repository every time BitBake parses your recipe, you should specify a SRCREV that is a full revision identifier and not just a tag. S
12 Variables Glossary — The Yocto Project ® 4.3.999 documentation
已解压缩的配方要用的源代码其所在构建目录中的位置。默认情况下该目录为 ${WORKDIR}/${BPN}-${PV}其中 ${BPN} 是基本配方名称${PV} 是配方版本。如果源代码压缩包将代码提取到 ${BPN}-${PV} 以外的目录或者源代码是从 Git 或 Subversion 等 SCM 获取的则必须在配方中设置 S以便 OpenEmbedded 构建系统知道在哪里可以找到已解压的源代码。 The location in the Build Directory where unpacked recipe source code resides. By default, this directory is ${WORKDIR}/${BPN}-${PV}, where ${BPN} is the base recipe name and ${PV} is the recipe version. If the source tarball extracts the code to a directory named anything other than ${BPN}-${PV}, or if the source code is fetched from an SCM such as Git or Subversion, then you must set S in the recipe so that the OpenEmbedded build system knows where to find the unpacked source. 举例来说假设源代码目录的顶级文件夹名为 poky默认的编译目录为 poky/build。在这种情况下构建系统用来保存名为db的配方的解压文件的工作目录如下
As an example, assume a Source Directory top-level folder named poky and a default Build Directory at poky/build. In this case, the work directory the build system uses to keep the unpacked recipe for db is the following: poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19 解压后的源代码位于 db-5.1.19 文件夹中。
下一个示例假设有一个 Git 仓库。默认情况下Git 仓库会在 do_fetch 过程中克隆到 ${WORKDIR}/git。由于该路径与默认值 S 不同因此必须特别设置以便找到源代码 The unpacked source code resides in the db-5.1.19 folder.
This next example assumes a Git repository. By default, Git repositories are cloned to ${WORKDIR}/git during do_fetch. Since this path is different from the default value of S, you must set it specifically so the source can be located: SRC_URI git://path/to/repo.git;branchmain
S ${WORKDIR}/git FETCHERS
4 File Download Support — Bitbake dev documentation 4.3 Fetchers
如前所述URL 前缀决定了 BitBake 使用哪个提取子模块。每个子模块可以支持不同的 URL 参数下面将对此进行介绍。
As mentioned earlier, the URL prefix determines which fetcher submodule BitBake uses. Each submodule can support different URL parameters, which are described in the following sections. 4.3.1 Local file fetcher (file://) #本地文件提取器 该子模块处理以 file:// 开头的 URL。在 URL 中指定的文件名可以是文件的绝对路径也可以是相对路径。如果文件名是相对路径则使用 FILESPATH 变量的内容与 PATH 用于查找可执行文件的方式相同。如果找不到文件则假定在调用download()方法时文件在 DL_DIR 中可用。
This submodule handles URLs that begin with file://. 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 FILESPATH variable is used in the same way PATH is used to find executables. If the file cannot be found, it is assumed that it is available in DL_DIR by the time the download() method is called. 如果指定一个目录则整个目录都会被解压缩。
下面是几个 URL 示例第一个是相对 URL第二个是绝对 URL
If you specify a directory, the entire directory is unpacked.
Here are a couple of example URLs, the first relative and the second absolute: SRC_URI file://relativefile.patch
SRC_URI file:///Users/ich/very_important_software 4.3.5 Git Fetcher (git://) #Git仓库提取器 这个提取子模块从 Git 源代码控制系统中取回代码。提取器的工作原理是在 GITDIR通常是 DL_DIR/git2中创建一个远程的裸克隆。然后从裸克隆中再clone到工作目录也就是checkout一个特定的tree解压到工作目录。这样做是为了尽量减少磁盘上的重复数据量并使解包过程更快。使用的可执行文件可通过 FETCHCMD_git 设置。
This fetcher submodule fetches code from the Git source control system. The fetcher works by creating a bare clone of the remote into GITDIR, which is usually DL_DIR/git2. This bare clone is then cloned into the work directory during the unpack stage when a specific tree is checked out. This is done using alternates and by reference to minimize the amount of duplicate data on the disk and make the unpack process fast. The executable used can be set with FETCHCMD_git. 此提取器支持的参数如下 “protocol”: The protocol used to fetch the files. The default is “git” when a hostname is set. If a hostname is not set, the Git protocol is “file”. You can also use “http”, “https”, “ssh” and “rsync”. “nocheckout”: Tells the fetcher to not checkout source code when unpacking when set to “1”. Set this option for the URL where there is a custom routine to checkout code. The default is “0”. “rebaseable”: Indicates that the upstream Git repository can be rebased. You should set this parameter to “1” if revisions can become detached from branches. In this case, the source mirror tarball is done per revision, which has a loss of efficiency. Rebasing the upstream Git repository could cause the current revision to disappear from the upstream repository. This option reminds the fetcher to preserve the local cache carefully for future use. The default value for this parameter is “0”. “nobranch”: Tells the fetcher to not check the SHA validation for the branch when set to “1”. The default is “0”. Set this option for the recipe that refers to the commit that is valid for any namespace (branch, tag, …) instead of the branch. “bareclone”: Tells the fetcher to clone a bare clone into the destination directory without checking out a working tree. Only the raw Git metadata is provided. This parameter implies the “nocheckout” parameter as well. “branch”: The branch(es) of the Git tree to clone. Unless “nobranch” is set to “1”, this is a mandatory parameter. The number of branch parameters must match the number of name parameters. “rev”: The revision to use for the checkout. The default is “master”. “tag”: Specifies a tag to use for the checkout. To correctly resolve tags, BitBake must access the network. For that reason, tags are often not used. As far as Git is concerned, the “tag” parameter behaves effectively the same as the “rev” parameter. “subpath”: Limits the checkout to a specific subpath of the tree. By default, the whole tree is checked out. “destsuffix”: The name of the path in which to place the checkout. By default, the path is git/. “usehead”: Enables local git:// URLs to use the current branch HEAD as the revision for use with AUTOREV. The “usehead” parameter implies no branch and only works when the transfer protocol is file://. 注意
在使用protocol参数时当协议为 ssh 时SRC_URI中的预期URL 与通常传递给 git clone 命令的不同后者是由 Git 服务器提供的URL来提取内容的。例如通过 SSH 克隆时GitLab 服务器返回的 mesa 的 URL 是 gitgitlab.freedesktop.org:mesa/mesa.git但 SRC_URI 中的预期 URL 却如下 SRC_URI git://gitgitlab.freedesktop.org/mesa/mesa.git;branchmain;protocolssh;... 注意项目路径前的:字符改为/。 一些URL的例子如下
SRC_URI git://github.com/fronteed/icheck.git;protocolhttps;branch${PV};tag${PV}
SRC_URI git://github.com/asciidoc/asciidoc-py;protocolhttps;branchmain
SRC_URI git://gitgitlab.freedesktop.org/mesa/mesa.git;branchmain;protocolssh;... 当使用 git 作为软件主源代码的获取器时应相应地设置 S
S ${WORKDIR}/git 注意
不支持在 git:// urls 中直接指定密码。原因有几个 SRC_URI 通常会被写入日志或其他地方这很容易泄露密码而且不删除密码的话会导致元数据共享太容易。可以使用 SSH 密钥、~/.netrc 和 ~/.ssh/config 文件作为替代。 在 git fetcher 中使用标签可能会导致令人惊讶的行为。Bitbake 需要将标签解析到特定版本为此必须连接并使用上游版本库(upstream repository)。这是因为标签(tag)指向的版本(revision)可能会发生变化我们曾在著名的公共软件源中看到过这种情况。这可能意味着网络连接比预期的要多得多而且每次构建时都要重新解析配方。源镜像(Source mirrors)也会被绕过因为上游版本库是准确解析版本的唯一真实来源。出于这些原因虽然提取器可以支持标签但我们还是建议在配方中具体指定修订版本。 联合起来使用
通过上面的介绍在bb文件中通过这些变量来获取需要构建的目标文件的源代码。 比如项目里通常会使用git协议来获取源代码。而在本地调试时可以修改称本地路径。 第一种
SRC_URI git://gitgithub.com:7999/platform/projectname.git;protocolssh;nobranch1
SRCREV c3f56703e58af33dbf808f903de694bcde3269cd
S ${WORKDIR}/git 第二种
SRC_URI file://${TOPDIR}/../../projectname
S ${WORKDIR}/${TOPDIR}/../../projectname 这里用到了${TOPDIR}。 (结束)
