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文件夹里的头文件以及库文件拷贝到此目录

 

 

 

 

 

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(yocto)