bitbake中bb文件的描述

SUMMARY = "Linux Bluetooth Stack Userland V5"
# 用於打包系統（例如opkg，rpm或dpkg）的二進制包的（72個字符或更少）摘要。
默認情況下，如果在配方中未設置DESCRIPTION，則使用SUMMARY值的定義描述變量。
DESCRIPTION = "Linux Bluetooth stack V5 userland components.
These include a system configurations, daemons, tools and system libraries."
# 提供給包管理器的包描述信息。如果未設置，說明將使用內容變量的值
HOMEPAGE = "http://www.bluez.org"
# 一般為配方的正在構建的軟件的主頁，從中可以獲取更多的軟件信息。
SECTION = "libs"
# 用於對軟件包進行分類，此變量用於軟件包管理程序。
LICENSE = "GPLv2+ & LGPLv2.1+"
# 配方的源文件許可列表.LICENSE需遵循以下規則：
# 　　（1）不要在單個許可名稱中使用空格
# 　　（2）當許可可選擇多個時，使用| 分隔許可證。
# 　　（3）當存在涵蓋源文件的不同部分的多個許可證時，使用與分隔許可證。
# 　　（4）您可以在許可名稱之間使用空格。
# 　　（5）對於標準許可，請使用元/文件/ common-licenses /中的LICENSE，
或者在meta / conf / licenses.conf中定義的具有SPDXLICENSEMAP標誌的LICENSE。
# 下面是一些例子：
# LICENSE =「LGPLv2.1 | GPLv3」
# LICENSE =「MPL-1＆LGPLv2.1」
# LICENSE =「GPLv2 +」
# 第一個示例來自Qt的配方，源文件可以選擇LGPLv2.1或GPLv3許可。第二個示例來自Cairo，其中兩個LICENSE涵蓋源代碼的不同部分。
最後一個示例來自sysstat，它提供了一個單一的LICENSE。
# 您還可以針對每個包指定LICENSE以處理輸出組件具有不同的LICENSE情況。
例如，如果某個軟件的代碼根據GPLv2許可，但是文檔卻根據GNU 1.2自由文檔許可，其LICENSE可以被規定如下:
# LICENSE =「GFDL-1.2＆GPLv2」
# LICENSE _ $ {PN} =「GPLv2」
# LICENSE _ $ {PN} -doc =「GFDL-1.2」
LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e"
# 配方文件構建的軟件源代碼中的許可文本的校驗和。
# 此變量跟蹤軟件源代碼文件的許可文本的更改。如果許可文本被更改，它將觸發構建失敗，這使開發人員有機會審查任何許可更改。
# 所有配方文件必須定義此變量（除非許可設置為「關閉」）。
DEPENDS = "udev libusb dbus-glib glib-2.0 libcheck readline"
# 列出配方的構建時的依賴項（即其他配方文件）。
在執行配方的配置任務之前，系統確保列出的所有依賴項都已構建，並且所有依賴項的內容已經保存在相應的 sysroot 中。
# 考慮這個簡單的例子，兩個名為「a」和「b」的配方生成類似命名的包。
在本示例中，DEPENDS語句出現在「a」配方中：
# DEPENDS =「b」
# 這裡，DEPENDS使得配方「a」的do_configure任務取決於配方「b」的do_populate_sysroot任務。
這意味著當配方「a」正在配置自身時，配方「b」放入sysroot的任何內容都必須可用。
PROVIDES += "bluez-hcidump"
# 用於提供配方的別名。默認情況下，配方自己的PN已經包含在PROVIDES列表中。
如果配方使用PROVIDES，則別名是配方的PN的同義詞，並可用於其他配方的DEPENDS中。
# 以配方文件libav_0.8.11.bb為例，libav_0.8.11.bb中的現狀提供語句如下：
# PROVIDES += 「libpostproc」
# 該現狀提供語句使得「libav」配方也被稱為「libpostproc」。
RPROVIDES_${PN} += "bluez-hcidump"
# 用於提供包名的別名列表。這些別名用於滿足其他包在構造期間和指定目標時（在RDEPENDS所指定的）的運行時依賴。
# 注意
# 程序包自身的名稱（PN）已隱含在其。RPROVIDES中列表
# 與所有程序包控制變量一樣，您必須始終將該變量與包名結合使用例如：
# RPROVIDES_${PN} =「widget-abi-2」
RCONFLICTS_${PN} = "bluez4"
# 用於指定與當前軟件包衝突的軟件包列表。請注意，如果沒有先刪除衝突的包，則不會安裝當前軟件包。
# 與所有包控制變量一樣，您必須始終將其與包名結合使用。例如：
# RCONFLICTS _ $ {PN} =「another_conflicting_package_name」
# OpenEmbedded構架系統使用的BitBake支持指定衝突的軟件包版本。
雖然語法因為軟件打包格式而異，但BitBake會隱藏這些差異。
下面是使用RCONFLICTS變量指定衝突的軟件包的一般語法：
# RCONFLICTS _ $ {PN} =「package（operator version）」
# 對於運營商，以下內容說明了當前軟件包與軟件包FOO的1.2或更高版本衝突：
# RCONFLICTS _ $ {PN} =「foo（> = 1.2）」
PACKAGECONFIG ??= "obex-profiles"
PACKAGECONFIG[obex-profiles] = "--enable-obex,--disable-obex,libical"
PACKAGECONFIG[experimental] = "--enable-experimental,--disable-experimental,"
# 該變量提供了在配方上啟用或禁用配方的 feature 的方法您可以在配方中指定的 feature 以及 feature 的參數來創建PACKAGECONFIG塊以下是基本的塊結構。：
# PACKAGECONFIG ?? =「f1 f2 f3 ...」
# PACKAGECONFIG [f1] =「--with-f1， - without-f1，build-deps-f1，rt-deps-f1」
# PACKAGECONFIG [f2] =「--with-f2， - without-f2，build-deps-f2，rt-deps-f2」
# PACKAGECONFIG [f3] =「--with-f3， - without-f3，build-deps-f3，rt-deps-f3」
# PACKAGECONFIG首先指定了一個空格分隔的要啟用的功能列表。
在feature列表下面，您可以通過提供最多四個按順序排列的參數來確定每個 feature的行為，這些參數之間用逗號分隔。
您可以省略。
任何您喜歡的參數，但必須保留逗號分隔符您必須按照以下順序指定 feature的參數：
# 　　1.如果啟用了該功能，則應將額外的參數添加到配置腳本參數列表（EXTRA_OECONF）。
# 　　2.如果禁用了該功能，應該將額外的參數添加到EXTRA_OECONF。
# 　　3.如果啟用了該功能，則應添加附加的構建時依賴關係（DEPENDS）。
# 　　4.如果啟用了該功能，應該添加附加的運行時依賴關係（RDEPENDS）。
# 以的librsvg中的PACKAGECONFIG塊為例。
在這個例子中，feature是croco，它通過三個參數來確定其行為。
# PACKAGECONFIG ?? =「croco」
# PACKAGECONFIG [croco] =「 - with-croco，- without-croco，libcroco」
# –with-croco和libcroco參數僅在啟用此feature時適用。
在這種情況下，–with-croco將被添加到配置腳本的參數列表中，而libcroco將被添加到DEPENDS中。
另一方面，如果您通過另一層中的.bbappend文件禁用該功能，則第二個參數–without-croco將會被添加到配置腳本中，而不是–with-croco。
基本的PACKAGECONFIG結構適用於創建塊或者更改塊。
如果要更改現有的PACKAGECONFIG塊，可以採用以下兩種方法之一：
# 1.附加文件：在您的層（layer）中創建一個名為recipename.bbappend的附加文件，並覆蓋PACKAGECONFIG的值。您可以完全覆蓋變量的值：
# PACKAGECONFIG =「f4 f5」
# 或者，您可以只添加變量的值：
# PACKAGECONFIG_append =「f4」
# 2.配置文件：如果您沒有修改local.conf或mydistro.conf文件，此方法與通過附加文件更改塊相同。
與之前描述的附加文件一樣，您可以完全覆蓋變量的值：
# PACKAGECONFIG_pn-recipename =「f4 f5」
# 或者，您可以只修改變量的值：
# PACKAGECONFIG_append_pn-recipename =「f4」
SRC_URI = "\
${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
file://out-of-tree.patch \
file://set_device_class.patch \
file://init \
file://run-ptest \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \
file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
"
# 用於指定源文件列表（本地或遠程）。
這個變量告訴OpenEmbedded構建系統哪些位要進入構建以及如何獲取它們。
例如，如果配方或附加文件只需要從Internet中提取壓縮後的源文件，則配方或附加文件只需使用單個SRC_URI條目即可。
另一方面，如果配方或附加文件需要同時獲取壓縮後的源文件，應用兩個補丁以及自定義文件，則配方或附加文件中的SRC_URI變量將包括四個條目。
# 以下列出了可用的URI協議：
# 　　file：//-從本地獲取文件，這些文件通常是元數據附帶的文件。
其路徑相對於FILESPATH變量。因此，構建系統按順序從配方文件（.bb）或附加文件（.bbappend）所在的目錄的子目錄中搜索：
# 1 ${BPN} - 沒有任何特殊後綴或版本號的配方名稱。
# 2 ${BP} - $ {BPN} - $ {PV}。配方的名稱和版本，但沒有任何特殊的包名稱後綴。
# files - files目錄中的文件，一般配方或附加文件旁邊。
# 　　注意：
# 　　如果希望構建系統從append文件中選取通過SRC_URI語句指定的文件，則可以通過在append文件中使用FILESEXTRAPATHS變量來擴展FILESPATH變量。
# 　　bzr：// - 從Bazaar版本控制存儲庫獲取文件。
# 　　git：// - 從Git版本控制存儲庫獲取文件。
# 　　osc：// - 從OSC（OpenSUSE Build服務）版本控制存儲庫獲取文件。
# 　　repo：// - 從repo（Git）存儲庫獲取文件。
# 　　ccrc：// - 從ClearCase存儲庫獲取文件。
# 　　http：// - 使用http從Internet獲取文件。
# 　　https：// - 使用https從Internet獲取文件。
# 　　ftp：// - 使用ftp從Internet獲取文件。
# 　　cvs：// - 從CVS版本控制存儲庫獲取文件。
# 　　hg：// - 從Mercurial（hg）版本控制存儲庫獲取文件。
# 　　p4：// - 從Perforce（p4）版本控制存儲庫獲取文件。
# 　　ssh：// - 從安全shell獲取文件。
# 　　svn：// - 從Subversion（svn）版本控制存儲庫獲取文件。
# 針對SRC_URI的每個條目還有一些標準和特定的配方選項。以下是標準選項：
# 　　apply - 是否應用補丁。默認操作是應用補丁。
# 　　striplevel - 應用補丁時使用的級別。默認級別為1。
# 　　patchdir - 指定補丁的目錄。默認值為$ {S}。
# 以下是版本控制系統針對配方構建代碼的選項：
# 　　mindate - 只有在SRCDATE等於或大於mindat時才應用補丁
# 　　maxdate - 僅當SRCDATE不晚於mindate時才應用補丁。
# 　　minrev - 僅當SRCREV等於或大於minrev時才應用補丁。
# 　　maxrev - 僅當SRCREV不晚於maxrev時才應用補丁。
# 　　rev - 僅當SRCREV等於rev時才應用補丁。
# 　　notrev - 僅當SRCREV不等於rev時才應用補丁。
# 這裡還有一些值得一提的額外選項：
# 　　unpack - 控制是否解壓縮文件（如果是歸檔文件）。默認操作是解壓縮文件。
# 　　subdir - 將文件（或提取其內容）放置到WORKDIR的指定子目錄中。
此選項對於異常tarball或其他那些解壓後文件不放置在子目錄的歸檔文件非常有用。
# 　　name - 當SRC_URI中有多個文件時，指定與SRC_URI校驗相關的名稱。
# 　　downloadfilename - 指定存儲下載文件時使用的文件名。
S = "${WORKDIR}/bluez-${PV}"
# 配方文件中源文件解壓縮後在build目錄中的位置。此位置在工作目錄（WORKDIR）中，且不是靜態的。
解壓縮後的源文件位置取決於配方名稱（PN）和配方版本（PV），如下所示：
# $ {WORKDIR} / $ {PN} - $ {PV}
# 例如，假設一個名為poky的源目錄頂級文件夾和一個poky / build的默認構建目錄。
在這種情況下，構建系統用於保留db配方源文件解壓縮後的目錄如下：
# poky / build / tmp / work / qemux86-poky-linux / db / 5.1.19-r3 / db-5.1.19
inherit autotools pkgconfig systemd update-rc.d distro_features_check ptest
# 用於指定在解析過程中應繼承的類。該變量僅在配置文件中有效。
EXTRA_OECONF = "\
--enable-tools \
--disable-cups \
--enable-test \
--enable-datafiles \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '--enable-systemd', '--disable-systemd', d)} \
--enable-library \
"
# 指定用於configure 的參數。
# bluez5 builds a large number of useful utilities but does not
# install them. Specify which ones we want put into ${PN}-noinst-tools.
NOINST_TOOLS_READLINE ??= ""
NOINST_TOOLS_EXPERIMENTAL ??= ""
NOINST_TOOLS = " \
${NOINST_TOOLS_READLINE} \
${@bb.utils.contains('PACKAGECONFIG', 'experimental', '${NOINST_TOOLS_EXPERIMENTAL}', '', d)} \
"
do_install_append() {
install -d ${D}${INIT_D_DIR}
# 目標目錄。do_install任務在build目錄中安裝組件的位置。此位置默認為：
# $ {WORKDIR} / image
install -m 0755 ${WORKDIR}/init ${D}${INIT_D_DIR}/bluetooth
# OpenEmbedded構建系統構建配方的工作目錄的路徑名。
此目錄位於TMPDIR目錄結構中，並且特定於正在構建的配方和正在構建的系統。
# WORKDIR目錄定義如下：
# $ {TMPDIR} / work / $ {MULTIMACH_TARGET_SYS} / $ {PN} / $ {EXTENDPE} $ {PV} - $ {PR}
# 1
# 實際目錄取決於幾個事情：
# 　　TMPDIR：最上層構建輸出目錄
# 　　MULTIMACH_TARGET_SYS：目標系統
# 　　PN：配方名稱
# 　　EXTENDPE：時間戳？ - （如果PE未指定，這通常是大多數配方的情況，則EXTENDPE為空）
# 　　PV：配方版本
# 　　PR：配方修訂版
# 例如，假設源目錄最上層文件夾名稱為poky，默認構建目錄為poky/build，目標系統為qemux86-poky-linux。此外，假設您的配方名為foo_1.3.0-r0.bb。在這種情況下，構建系統用於構建包的工作目錄（WORKDIR）將如下所示：
# poky / build / tmp / work / qemux86-poky-linux / foo / 1.3.0-r0
install -d ${D}${sysconfdir}/bluetooth/
if [ -f ${S}/profiles/audio/audio.conf ]; then
# 配方文件中源文件解壓縮後在build目錄中的位置。
此位置在工作目錄（WORKDIR）中，且不是靜態的。解壓縮後的源文件位置取決於配方名稱（PN）和配方版本（PV），如下所示：
install -m 0644 ${S}/profiles/audio/audio.conf ${D}/${sysconfdir}/bluetooth/
# 配置文件中源文件解壓縮後在build目錄中的位置。
此位置在工作目錄（WORKDIR）中，並且不是靜態的。解壓縮後的源文件位置取決於配置名稱（PN）和配方版本（PV），如下所示：
# $ {WORKDIR} / $ {PN} - $ {PV}
# 例如，假設一個名為poky的源目錄頂級文件夾和一個poky / build的默認構造目錄。
在這種情況下，構建系統用於保留db配方源文件解壓縮後的目錄如下：
# poky / build / tmp / work / qemux86-poky-linux / db / 5.1.19-r3 / db-5.1.19
fi
if [ -f ${S}/profiles/network/network.conf ]; then
install -m 0644 ${S}/profiles/network/network.conf ${D}/${sysconfdir}/bluetooth/
fi
if [ -f ${S}/profiles/input/input.conf ]; then
install -m 0644 ${S}/profiles/input/input.conf ${D}/${sysconfdir}/bluetooth/
fi
if [ -f ${S}/src/main.conf ]; then
install -m 0644 ${S}/src/main.conf ${D}/${sysconfdir}/bluetooth/
fi
if [ -f ${D}/${sysconfdir}/init.d/bluetooth ]; then
sed -i -e 's#@LIBEXECDIR@#${libexecdir}#g' ${D}/${sysconfdir}/init.d/bluetooth
fi
# Install desired tools that upstream leaves in build area
for f in ${NOINST_TOOLS} ; do
install -m 755 ${B}/$f ${D}/${bindir}
done
}
ALLOW_EMPTY_libasound-module-bluez = "1"
PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex ${PN}-noinst-tools"
FILES_libasound-module-bluez = "${libdir}/alsa-lib/lib*.so ${datadir}/alsa"
FILES_${PN} += "${libdir}/bluetooth/plugins/*.so ${base_libdir}/udev/ ${nonarch_base_libdir}/udev/ ${systemd_unitdir}/ ${datadir}/dbus-1"
# 指定需要放入包中的目錄或文件的列表。
# 使用FILES變量時，必須與生成包的包名結合使用。然後提供一個空格分隔的文件或路徑列表，用於標識要包含在生成包中的文件。例如：
# FILES _ $ {PN} + =「$ {bindir} / mydir1 / $ {bindir} / mydir2 / myfile」
# 1
# 注意:
# 當為FILES變量指定文件或路徑時，最好使用相對路徑。
例如，使用sysconfdir而不是/etc，或 {bindir}而不是/ usr / bin。您可以在源目錄中的meta / conf / bitbake.conf文件的頂部找到這些變量的列表。
# 如果您提供的FILES變量中的一些文件是可編輯的，並且您知道它們不應該在軟件包管理系統（PMS）的軟件包更新過程中被覆蓋，您可以讓PMS識別這些文件，以便PMS不會覆蓋它們。
有關如何使PMS的識別這些文件，請參考CONFFILES變量。
FILES_${PN}-dev += "\
${libdir}/bluetooth/plugins/*.la \
${libdir}/alsa-lib/*.la \
"
FILES_${PN}-obex = "${libexecdir}/bluetooth/obexd \
${exec_prefix}/lib/systemd/user/obex.service \
${datadir}/dbus-1/services/org.bluez.obex.service \
"
SYSTEMD_SERVICE_${PN}-obex = "obex.service"
# 如果配方繼承了systemd類，那麼此變量為配方生成包的指定了systemd的服務名稱。
當您在配方中使用此文件時，請指定包名，以保證變量值應用到目標包上。下面是一個來自connman配方中的例子：
# SYSTEMD_SERVICE _ $ {PN} =「connman.service」
FILES_${PN}-testtools = "${libdir}/bluez/test/*"
def get_noinst_tools_paths (d, bb, tools):
s = list()
bindir = d.getVar("bindir", True)
for bdp in tools.split():
f = os.path.basename(bdp)
s.append("%s/%s" % (bindir, f))
return "\n".join(s)
FILES_${PN}-noinst-tools = "${@get_noinst_tools_paths(d, bb, d.getVar('NOINST_TOOLS', True))}"
RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"
# 列出包的運行時依賴關係（即其他程序包），依賴包必須先安裝才能使當前構建的程序包正常運行。
如果在構建過程中找不到此列表中的依賴包，構建將會失敗。
# 當在配方中使用RDEPENDS變量時，說明當前配方的do_build任務取決於特定包。
下面以兩個名為「a」和「b」的配方為例，它們生成類似命名的IPK包。在此示例中，RDEPENDS語句顯示在「a」配方中：
# RDEPENDS _ $ {PN} =「b」
#
# 這裡，RDEPENDS使得配方「a」的do_build任務取決於配方「b」的do_package_write_ipk任務。
這意味著當構建配方「a」時，「b」的包文件必須可用。更重要的是，以包管理器理解的方式，包「a」將被標記為依賴於包「b。
# 在RDEPENDS中列出的包的名稱必須是其他包的名稱 - 它們不能是配方名稱。
雖然軟件包名稱和配方名稱通常匹配，但重要的是，您必須在RDEPENDS變量中提供軟件包名稱。
有關如何從配方創建軟件包的示例，請參考PACKAGES變量。
# 因為RDEPENDS變量適用於正在構建的包，所以您應該始終使用帶有附加的包名稱的形式的變量名。
例如，假設您正在構建一個依賴於perl包的開發包。在這種情況下，您將使用以下RDEPENDS語句：
# RDEPENDS _ $ {PN} -dev + =「perl」
#
# 在該示例中，RDEPENDS變量具有$ {PN} -dev包名稱作為變量名的一部分。
# 附加到RDEPENDS變量的程序包，在通過類（如debian）重命名之前，其包名必需同PACKAGES命名空間中的名稱一致。
# 在許多情況下，您不需要使用RDEPENDS顯式添加運行時的依賴包，因為配方會自動運行某些處理：
# shlibdeps：如果運行時的程序包包含共享庫（.so），構建過程中將處理庫以及與其動態鏈接的其他庫，並在創建運行時的包時將這些庫添加到RDEPENDS。
# pcdeps：如果程序包含有pkg-config文件，則構建過程中將使用此文件將條目添加到RDEPENDS變量以創建運行時的程序包。
# OpenEmbedded構建系統使用的BitBake支持依賴指定版本的特性。
雖然語法因軟件包打包格式而異，但BitBake會隱藏這些差異。以下是使用RDEPENDS變量指定依賴軟件包版本的一般語法：
# RDEPENDS _ $ {PN} =「package（operator version）」
# 1
# 對於operator，您可以指定以下內容：
# =,<,>,<=,>=
#
# 例如，以下內容說明配方運行時依賴軟件包foo的1.2或更高版本：
# RDEPENDS _ $ {PN} =「foo（> = 1.2）」
#
# 有關構建時依賴的內容，請參考DEPENDS變量
SYSTEMD_SERVICE_${PN} = "bluetooth.service"
INITSCRIPT_PACKAGES = "${PN}"
# 包含初始化的軟件包列表。如果有多個包，則應該使用帶有附加的包名稱的形式的變量名。
# 只有配方繼承update-rc.d.bbclass，此變量才可使用。該變量是可選的且默認為值為PN。
INITSCRIPT_NAME_${PN} = "bluetooth"
# 安裝到$ {sysconfdir} /init.d的初始化腳本名。
# 只有配方繼承update-rc.d.bbclass，此變量才可使用。此變量是必需的。
EXCLUDE_FROM_WORLD = "1"
# 將當前配方從BitBake world 中排除。
在執行BitBake world期間，BitBake會定位，解析和構建在bblayers.conf配置文件中公開的每一層的配方。
# 如果需要BitBake world不構建當前配方，請在配方中將EXCLUDE_FROM_WORLD變量設置為「1」。
# 注意:
# 如果有其他配方依賴於設置EXCLUDE_FROM_WORLD的值為1的配方，則此配方仍然可能被BitBake world構建。
將EXCLUDE_FROM_WORLD設置為1,僅確保配方未顯式添加到BitBake world的構建目標列表中。
do_compile_ptest() {
oe_runmake buildtests
}
do_install_ptest() {
cp -r ${B}/unit/ ${D}${PTEST_PATH}
rm -f ${D}${PTEST_PATH}/unit/*.o
}

poky/meta/conf/bitbake.conf + build/conf/local.conf定理了bb文件里面的路径引用

sysroot_descdir,yocto会自动把当前bb想要传递出去的头文件以及库文件放入此目录

recipe-sysroo,yocto会自动把当前bb DEPENDS的bb文件的sysroot_descdir文件夹里的头文件以及库文件拷贝到此目录

bitbake中bb文件的描述相关推荐

陈力：传智播客古代珍宝币泡泡龙游戏开发第47讲：PHP程序设计中的文件操作
陈力:传智播客古代珍宝币泡泡龙游戏开发第47讲:PHP程序设计中的文件操作描述:PHP程序设计语言中文件操作的函数很多,如何获取文件的信息,如果打开文件,如果关闭文件,读取文件,写入文件,复制文 ...
如何从 Git 存储库中删除文件？
问: 如何从我的存储库中删除 "file1.txt"? 答1: huntsbot.com – 程序员副业首选,一站式外包任务.远程工作.创意产品分享订阅平台. 使用 git rm. ...
bitbake.bb文件解析[转]
SUMMARY = "Linux Bluetooth Stack Userland V5" # 用於打包系統(例如opkg,rpm或dpkg)的二進制包的(72個字符或更少)摘要. ...
Yocto系列讲解[实战篇]44 - bb文件中函数实操演示(2)
By: fulinux E-mail: fulinux@sina.com Blog: https://blog.csdn.net/fulinus 喜欢的盆友欢迎点赞和订阅! 你的喜欢就是我写作的动力! ...
Linux中文件描述符1,linux内核中的文件描述符(一)--基础知识简介
原标题:linux内核中的文件描述符(一)--基础知识简介 Kernel version:2.6.14 CPU architecture:ARM920T Author:ce123(http://blo ...
Linux中的文件描述符与打开文件之间的关系
1. 概述在Linux系统中一切皆可以看成是文件,文件又可分为:普通文件.目录文件.链接文件和设备文件.文件描述符(file descriptor)是内核为了高效管理已被打开的文件所创建的索引,其是 ...
linux c中的文件描述符与打开文件之间的关系
转载请说明出处:http://blog.csdn.net/cywosp/article/details/38965239 1. 概述在Linux系统中一切皆可以看成是文件,文件又可分为:普通 ...
Linux中对文件描述符的操作(FD_ZERO、FD_SET、FD_CLR、FD_ISSET
在Linux中,内核利用文件描述符(File Descriptor)即文件句柄,来访问文件.文件描述符是非负整数.打开现存文件或新建文件时,内核会返回一个文件描述符.读写文件也需要使用文件描述符来指定 ...
linux内核中的文件描述符(四)--fd的分配--get_unused_fd
linux内核中的文件描述符(四)--fd的分配--get_unused_fd Kernel version:2.6.14 CPU architecture:ARM920T Author:ce123( ...

bitbake中bb文件的描述

bitbake中bb文件的描述相关推荐

最新文章

热门文章