xmake v2.5.2 發佈, 支持自動拉取交叉工具鏈和依賴包集成

時間  2021-08-12
標籤 html linux c++ git github macos windows bash markdown 架構 欄目 設計模式 简体版
原文   原文鏈接

xmake 是一個基於 Lua 的輕量級跨平臺構建工具，使用 xmake.lua 維護項目構建，相比 makefile/CMakeLists.txt，配置語法更加簡潔直觀，對新手很是友好，短期內就能快速入門，可以讓用戶把更多的精力集中在實際的項目開發上。html

在 2.5.2 版本中，咱們增長了一個重量級的新特性：自動拉取遠程交叉編譯工具鏈。linux

這是用來幹什麼的呢，作過交叉編譯以及有 C/C++ 項目移植經驗的同窗應該知道，折騰各類交叉編譯工具鏈，移植編譯項目是很是麻煩的一件事，須要本身下載對應工具鏈，而且配置工具鏈和編譯環境很容易出錯致使編譯失敗。c++

如今，xmake 已經能夠支持自動下載項目所需的工具鏈，而後使用對應工具鏈直接編譯項目，用戶不須要關心如何配置工具鏈，任何狀況下只須要執行 xmake 命令便可完成編譯。git

甚至對於 C/C++ 依賴包的集成，也能夠自動切換到對應工具鏈編譯安裝集成，一切徹底自動化，徹底不須要用戶操心。github

除了交叉編譯工具鏈，咱們也能夠自動拉取工具鏈，好比特定版本的 llvm，llvm-mingw, zig 等各類工具鏈來參與編譯 C/C++/Zig 項目的編譯。macos

即便是 cmake 也還不支持工具鏈的自動拉取，頂多只能配合 vcpkg/conan 等第三方包管理對 C/C++ 依賴包進行集成，另外，即便對於 C/C++依賴包，xmake 也有本身原生內置的包管理工具，徹底無任何依賴。windows

新特性介紹

自動拉取遠程交叉編譯工具鏈

從 2.5.2 版本開始，咱們能夠拉取指定的工具鏈來集成編譯項目，咱們也支持將依賴包切換到對應的遠程工具鏈參與編譯後集成進來。bash

相關例子代碼見：Toolchain/Packages Examplesmarkdown

相關的 issue #1217架構

當前，咱們已經在 xmake-repo 倉庫收錄瞭如下工具鏈包，可讓 xmake 遠程拉取集成：

  • llvm
  • llvm-mingw
  • gnu-rm
  • muslcc
  • zig

雖然如今支持的工具鏈包很少，當可是總體架構已經打通，後期咱們只須要收錄更多的工具鏈進來就行，好比：gcc, tinyc, vs-buildtools 等工具鏈。

因爲 xmake 的包支持語義版本，所以若是項目依賴特定版本的 gcc/clang 編譯器，就不要用戶去折騰安裝了，xmake 會自動檢測當前系統的 gcc/clang 版本是否知足需求。

若是版本不知足，那麼 xmake 就會走遠程拉取，自動幫用戶安裝集成特定版本的 gcc/clang，而後再去編譯項目。

拉取指定版本的 llvm 工具鏈

咱們使用 llvm-10 中的 clang 來編譯項目。

add_requires("llvm 10.x", {alias = "llvm-10"})
target("test")
    set_kind("binary")
    add_files("src/*.c) set_toolchains("llvm@llvm-10") 複製代碼

其中，llvm@llvm-10 的前半部分爲工具鏈名，也就是 toolchain("llvm")，後面的名字是須要被關聯工具鏈包名，也就是 package("llvm")，不過若是設置了別名，那麼會優先使用別名：llvm-10

另外，咱們後續還會增長 gcc 工具鏈包到 xmake-repo，使得用戶能夠自由切換 gcc-10, gcc-11 等特定版本的 gcc 編譯器，而無需用戶去手動安裝。

拉取交叉編譯工具鏈

咱們也能夠拉取指定的交叉編譯工具鏈來編譯項目。

add_requires("muslcc")
target("test")
    set_kind("binary")
    add_files("src/*.c) set_toolchains("@muslcc") 複製代碼

muslcc 是 musl.cc 提供的一款交叉編譯工具鏈，默認 xmake 會自動集成編譯 x86_64-linux-musl- 目標平臺。

固然，咱們也能夠經過 xmake f -a arm64 切換到 aarch64-linux-musl- 目標平臺來進行交叉編譯。

拉取工具鏈而且集成對應工具鏈編譯的依賴包

咱們也可使用指定的muslcc交叉編譯工具鏈去編譯和集成全部的依賴包。

add_requires("muslcc")
add_requires("zlib", "libogg", {system = false})

set_toolchains("@muslcc")

target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("zlib", "libogg")
複製代碼

這個時候，工程裏面配置的 zlib, libogg 等依賴包，也會切換使用 muslcc 工具鏈，自動下載編譯而後集成進來。

咱們也能夠經過 set_plat/set_arch 固定平臺，這樣只須要一個 xmake 命令，就能夠完成整個交叉編譯環境的集成以及架構切換。

add_requires("muslcc")
add_requires("zlib", "libogg", {system = false})

set_plat("cross")
set_arch("arm64")
set_toolchains("@muslcc")

target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("zlib", "libogg")
複製代碼

完整例子見：Examples (muslcc)

拉取集成 Zig 工具鏈

xmake 會先下載特定版本的 zig 工具鏈，而後使用此工具鏈編譯 zig 項目，固然用戶若是已經自行安裝了 zig 工具鏈，xmake 也會自動檢測對應版本是否知足，若是知足需求，那麼會直接使用它，無需重複下載安裝。

add_rules("mode.debug", "mode.release")
add_requires("zig 0.7.x")

target("test")
    set_kind("binary")
    add_files("src/*.zig")
    set_toolchains("@zig")
複製代碼

增長對 zig cc 編譯器支持

zig cc 是 zig 內置的 c/c++ 編譯器，能夠徹底獨立進行 c/c++ 代碼的編譯和連接，徹底不依賴 gcc/clang/msvc，很是給力。

所以，咱們徹底可使用它來編譯 c/c++ 項目，關鍵是 zig 的工具鏈還很是輕量，僅僅幾十M 。

咱們只須要切換到 zig 工具鏈便可完成編譯：

$ xmake f --toolchain=zig
$ xmake
[ 25%]: compiling.release src/main.c
"zig cc" -c -arch x86_64 -fvisibility=hidden -O3 -DNDEBUG -o build/.objs/xmake_test/macosx/x86_64/release/src/main.c.o src/main.c
[ 50%]: linking.release test
"zig c++" -o build/macosx/x86_64/release/test build/.objs/xmake_test/macosx/x86_64/release/src/main.c.o -arch x86_64 -stdlib=libc++ -Wl,-x -lz
[100%]: build ok!
複製代碼

另外，zig cc 的另一個強大之處在於，它還支持不一樣架構的交叉編譯，太 happy 了。

經過 xmake，咱們也只需再額外切換下架構到 arm64，便可實現對 arm64 的交叉編譯，例如：

$ xmake f -a arm64 --toolchain=zig
$ xmake
[ 25%]: compiling.release src/main.c
"zig cc" -c -target aarch64-macos-gnu -arch arm64 -fvisibility=hidden -O3 -DNDEBUG -o build/.objs/xmake_test/macosx/arm64/release/src/main.c.o src/main.c
checking for flags (-MMD -MF) ... ok
checking for flags (-fdiagnostics-color=always) ... ok
[ 50%]: linking.release xmake_test
"zig c++" -o build/macosx/arm64/release/xmake_test build/.objs/xmake_test/macosx/arm64/release/src/main.c.o -target aarch64-macos-gnu -arch arm64 -stdlib=libc++ -Wl,-x -lz
[100%]: build ok!
複製代碼

即便你是在在 macOS，也能夠用 zig cc 去交叉編譯 windows/x64 目標程序，至關於替代了 mingw 乾的事情。

$ xmake f -p windows -a x64 --toolchain=zig
$ xmake
複製代碼

自動導出全部 windows/dll 中的符號

cmake 中有這樣一個功能：WINDOWS_EXPORT_ALL_SYMBOLS，安裝 cmake 文檔中的說法：

cmake.org/cmake/help/…

Enable this boolean property to automatically create a module definition (.def) file with all global symbols found in the input .obj files for a SHARED library (or executable with ENABLE_EXPORTS) on Windows. The module definition file will be passed to the linker causing all symbols to be exported from the .dll. For global data symbols, __declspec(dllimport) must still be used when compiling against the code in the .dll. All other function symbols will be automatically exported and imported by callers. This simplifies porting projects to Windows by reducing the need for explicit dllexport markup, even in C++ classes.

大致意思就是：

啓用此布爾屬性，能夠自動建立一個模塊定義(.def)文件，其中包含在Windows上的共享庫(或使用ENABLE_EXPORTS的可執行文件)的輸入.obj文件中找到的全部全局符號。 模塊定義文件將被傳遞給連接器，使全部符號從.dll中導出。對於全局數據符號，當對.dll中的代碼進行編譯時，仍然必須使用__declspec(dllimport)。 全部其它的函數符號將被調用者自動導出和導入。這就簡化了將項目移植到 Windows 的過程，減小了對顯式 dllexport 標記的需求，甚至在 C++ 類中也是如此。

如今，xmake 中也提供了相似的特性，能夠快速全量導出 windows/dll 中的符號，來簡化對第三方項目移植過程當中，對符號導出的處理。另外，若是項目中的符號太多，也能夠用此來簡化代碼中的顯式導出需求。

咱們只需在對應生成的 dll 目標上，配置 utils.symbols.export_all 規則便可。

target("foo")
    set_kind("shared")
    add_files("src/foo.c")
    add_rules("utils.symbols.export_all")

target("test")
    set_kind("binary")
    add_deps("foo")
    add_files("src/main.c")
複製代碼

xmake 會自動掃描全部的 obj 對象文件，而後生成 def 符號導出文件，傳入 link.exe 實現快速全量導出。

轉換 mingw/.dll.a 到 msvc/.lib

這個特性也是參考自 CMAKE_GNUtoMS 功能，能夠把MinGW生成的動態庫（xxx.dll & xxx.dll.a）轉換成Visual Studio能夠識別的格式（xxx.dll & xxx.lib），從而實現混合編譯。

這個功能對Fortran & C++混合項目特別有幫助，由於VS不提供fortran編譯器，只能用MinGW的gfortran來編譯fortran部分，而後和VS的項目連接。 每每這樣的項目同時有一些其餘的庫以vs格式提供，所以純用MinGW編譯也不行，只能使用cmake的這個功能來混合編譯。

所以，xmake 也提供了一個輔助模塊接口去支持它，使用方式以下：

import("utils.platform.gnu2mslib")

gnu2mslib("xxx.lib", "xxx.dll.a")
gnu2mslib("xxx.lib", "xxx.def")
gnu2mslib("xxx.lib", "xxx.dll.a", {dllname = "xxx.dll", arch = "x64"})
複製代碼

支持從 def 生成 xxx.lib ，也支持從 xxx.dll.a 自動導出 .def ，而後再生成 xxx.lib

具體細節見：issue #1181

實現批處理命令來簡化自定義規則

爲了簡化用戶自定義 rule 的配置，xmake 新提供了 on_buildcmd_file, on_buildcmd_files 等自定義腳本入口， 咱們能夠經過 batchcmds 對象，構造一個批處理命令行任務，xmake 在實際執行構建的時候，一次性執行這些命令。

這對於 xmake project 此類工程生成器插件很是有用，由於生成器生成的第三方工程文件並不支持 on_build_files 此類內置腳本的執行支持。

可是 on_buildcmd_file 構造的最終結果，就是一批原始的 cmd 命令行，能夠直接給其餘工程文件做爲 custom commands 來執行。

另外，相比 on_build_file，它也簡化對擴展文件的編譯實現，更加的可讀易配置，對用戶也更加友好。

rule("foo")
    set_extensions(".xxx")
    on_buildcmd_file(function (target, batchcmds, sourcefile, opt)
        batchcmds:vrunv("gcc", {"-o", objectfile, "-c", sourcefile})
    end)
複製代碼

除了 batchcmds:vrunv，咱們還支持一些其餘的批處理命令，例如：

batchcmds:show("hello %s", "xmake")
batchcmds:vrunv("gcc", {"-o", objectfile, "-c", sourcefile}, {envs = {LD_LIBRARY_PATH="/xxx"}})
batchcmds:mkdir("/xxx") -- and cp, mv, rm, ln ..
batchcmds:compile(sourcefile_cx, objectfile, {configs = {includedirs = sourcefile_dir, languages = (sourcekind == "cxx" and "c++11")}})
batchcmds:link(objectfiles, targetfile, {configs = {linkdirs = ""}})
複製代碼

同時，咱們在裏面也簡化對依賴執行的配置，下面是一個完整例子：

rule("lex")
    set_extensions(".l", ".ll")
    on_buildcmd_file(function (target, batchcmds, sourcefile_lex, opt)

        -- imports
        import("lib.detect.find_tool")

        -- get lex
        local lex = assert(find_tool("flex") or find_tool("lex"), "lex not found!")

        -- get c/c++ source file for lex
        local extension = path.extension(sourcefile_lex)
        local sourcefile_cx = path.join(target:autogendir(), "rules", "lex_yacc", path.basename(sourcefile_lex) .. (extension == ".ll" and ".cpp" or ".c"))

        -- add objectfile
        local objectfile = target:objectfile(sourcefile_cx)
        table.insert(target:objectfiles(), objectfile)

        -- add commands
        batchcmds:show_progress(opt.progress, "${color.build.object}compiling.lex %s", sourcefile_lex)
        batchcmds:mkdir(path.directory(sourcefile_cx))
        batchcmds:vrunv(lex.program, {"-o", sourcefile_cx, sourcefile_lex})
        batchcmds:compile(sourcefile_cx, objectfile)

        -- add deps
        batchcmds:add_depfiles(sourcefile_lex)
        batchcmds:set_depmtime(os.mtime(objectfile))
        batchcmds:set_depcache(target:dependfile(objectfile))
    end)
複製代碼

咱們從上面的配置能夠看到，總體執行命令列表很是清晰，而若是咱們用 on_build_file 來實現，能夠對比下以前這個規則的配置，就能直觀感覺到新接口的配置方式確實簡化了很多：

rule("lex")

    -- set extension
    set_extensions(".l", ".ll")

    -- load lex/flex
    before_load(function (target)
        import("core.project.config")
        import("lib.detect.find_tool")
        local lex = config.get("__lex")
        if not lex then
            lex = find_tool("flex") or find_tool("lex")
            if lex and lex.program then
                config.set("__lex", lex.program)
                cprint("checking for Lex ... ${color.success}%s", lex.program)
            else
                cprint("checking for Lex ... ${color.nothing}${text.nothing}")
                raise("lex/flex not found!")
            end
        end
    end)

    -- build lex file
    on_build_file(function (target, sourcefile_lex, opt)

        -- imports
        import("core.base.option")
        import("core.theme.theme")
        import("core.project.config")
        import("core.project.depend")
        import("core.tool.compiler")
        import("private.utils.progress")

        -- get lex
        local lex = assert(config.get("__lex"), "lex not found!")

        -- get extension: .l/.ll
        local extension = path.extension(sourcefile_lex)

        -- get c/c++ source file for lex
        local sourcefile_cx = path.join(target:autogendir(), "rules", "lex_yacc", path.basename(sourcefile_lex) .. (extension == ".ll" and ".cpp" or ".c"))
        local sourcefile_dir = path.directory(sourcefile_cx)

        -- get object file
        local objectfile = target:objectfile(sourcefile_cx)

        -- load compiler
        local compinst = compiler.load((extension == ".ll" and "cxx" or "cc"), {target = target})

        -- get compile flags
        local compflags = compinst:compflags({target = target, sourcefile = sourcefile_cx})

        -- add objectfile
        table.insert(target:objectfiles(), objectfile)

        -- load dependent info
        local dependfile = target:dependfile(objectfile)
        local dependinfo = option.get("rebuild") and {} or (depend.load(dependfile) or {})

        -- need build this object?
        local depvalues = {compinst:program(), compflags}
        if not depend.is_changed(dependinfo, {lastmtime = os.mtime(objectfile), values = depvalues}) then
            return
        end

        -- trace progress info
        progress.show(opt.progress, "${color.build.object}compiling.lex %s", sourcefile_lex)

        -- ensure the source file directory
        if not os.isdir(sourcefile_dir) then
            os.mkdir(sourcefile_dir)
        end

        -- compile lex
        os.vrunv(lex, {"-o", sourcefile_cx, sourcefile_lex})

        -- trace
        if option.get("verbose") then
            print(compinst:compcmd(sourcefile_cx, objectfile, {compflags = compflags}))
        end

        -- compile c/c++ source file for lex
        dependinfo.files = {}
        assert(compinst:compile(sourcefile_cx, objectfile, {dependinfo = dependinfo, compflags = compflags}))

        -- update files and values to the dependent file
        dependinfo.values = depvalues
        table.insert(dependinfo.files, sourcefile_lex)
        depend.save(dependinfo, dependfile)
    end)
複製代碼

關於這個的詳細說明和背景，見：issue 1246

依賴包配置改進

使用 add_extsources 改進包名查找

關於遠程依賴包定義這塊，咱們也新增了 add_extsources 和 on_fetch 兩個配置接口，能夠更好的配置 xmake 在安裝 C/C++ 包的過程當中，對系統庫的查找過程。

至於具體背景，咱們能夠舉個例子，好比咱們在 xmake-repo 倉庫新增了一個 package("libusb") 的包。

那麼用戶就能夠經過下面的方式，直接集成使用它：

add_requires("libusb")
target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("libusb")
複製代碼

若是用戶系統上確實沒有安裝 libusb，那麼 xmake 會自動下載 libusb 庫源碼，自動編譯安裝集成，沒啥問題。

但若是用戶經過 apt install libusb-1.0 安裝了 libusb 庫到系統，那麼按理 xmake 應該會自動優先查找用戶安裝到系統環境的 libusb 包，直接使用，避免額外的下載編譯安裝。

可是問題來了，xmake 內部經過 find_package("libusb") 並無找打它，這是爲何呢？由於經過 apt 安裝的 libusb 包名是 libusb-1.0, 而不是 libusb。

咱們只能經過 pkg-config --cflags libusb-1.0 才能找到它，可是 xmake 內部的默認 find_package 邏輯並不知道 libusb-1.0 的存在，因此找不到。

所以爲了更好地適配不一樣系統環境下，系統庫的查找，咱們能夠經過 add_extsources("pkgconfig::libusb-1.0") 去讓 xmake 改進查找邏輯，例如：

package("libusb")
    add_extsources("pkgconfig::libusb-1.0")
    on_install(function (package)
        -- ...
    end)
複製代碼

另外，咱們也能夠經過這個方式，改進查找 homebrew/pacman 等其餘包管理器安裝的包，例如：add_extsources("pacman::libusb-1.0")。

使用 on_fetch 徹底定製系統庫查找

若是不一樣系統下安裝的系統庫，僅僅只是包名不一樣，那麼使用 add_extsources 改進系統庫查找已經足夠，簡單方便。

可是若是有些安裝到系統的包，位置更加複雜，想要找到它們，也許須要一些額外的腳本才能實現，例如：windows 下注冊表的訪問去查找包等等，這個時候，咱們就能夠經過 on_fetch 徹底定製化查找系統庫邏輯。

仍是以 libusb 爲例，咱們不用 add_extsources，可使用下面的方式，實現相同的效果，固然，咱們能夠在裏面作更多的事情。

package("libusb")
    on_fetch("linux", function(package, opt)
        if opt.system then
            return find_package("pkgconfig::libusb-1.0")
        end
    end)
複製代碼

manifest 文件支持

在新版本中，咱們還新增了對 windows .manifest 文件的支持，只須要經過 add_files 添加進來便可。

add_rules("mode.debug", "mode.release")
target("test")
    set_kind("binary")
    add_files("src/*.cpp")
    add_files("src/*.manifest")
複製代碼

xrepo 命令改進

關於 xrepo 命令，咱們也稍微改進了下，如今能夠經過下面的命令，批量卸載刪除已經安裝的包，支持模式匹配：

$ xrepo remove --all
$ xrepo remove --all zlib pcr*
複製代碼

包的依賴導出支持

咱們也改進了 add_packages，使其也支持 {public = true} 來導出包配置給父 target。

add_rules("mode.debug", "mode.release")
add_requires("pcre2")

target("test")
    set_kind("shared")
    add_packages("pcre2", {public = true})
    add_files("src/test.cpp")

target("demo")
    add_deps("test")
    set_kind("binary")
    add_files("src/main.cpp")  -- 咱們能夠在這裏使用被 test 目標導出 pcre2 庫
複製代碼

至於具體導出哪些配置呢？

-- 默認私有，可是 links/linkdirs 仍是會自動導出
add_packages("pcre2")

-- 所有導出。包括 includedirs, defines
add_packages("pcre2", {public = true})
複製代碼

更新內容

新特性

  • #955: 支持 zig cc 和 zig c++ 做爲 c/c++ 編譯器
  • #955: 支持使用 zig 進行交叉編譯
  • #1177: 改進終端和 color codes 探測
  • #1216: 傳遞自定義 includes 腳本給 xrepo
  • 添加 linuxos 內置模塊獲取 linux 系統信息
  • #1217: 支持當編譯項目時自動拉取工具鏈
  • #1123: 添加 rule("utils.symbols.export_all") 自動導出全部 windows/dll 中的符號
  • #1181: 添加 utils.platform.gnu2mslib(mslib, gnulib) 模塊接口去轉換 mingw/xxx.dll.a 到 msvc xxx.lib
  • #1246: 改進規則支持新的批處理命令去簡化自定義規則實現
  • #1239: 添加 add_extsources 去改進外部包的查找
  • #1241: 支持爲 windows 程序添加 .manifest 文件參與連接
  • 支持使用 xrepo remove --all 命令去移除全部的包，而且支持模式匹配
  • #1254: 支持導出包配置給父 target，實現包配置的依賴繼承

改進

  • #1226: 添加缺失的 Qt 頭文件搜索路徑
  • #1183: 改進 C++ 語言標準，以便支持 Qt6
  • #1237: 爲 vsxmake 插件添加 qt.ui 文件
  • 改進 vs/vsxmake 插件去支持預編譯頭文件和智能提示
  • #1090: 簡化自定義規則
  • #1065: 改進 protobuf 規則，支持 compile_commands 生成器
  • #1249: 改進 vs/vsxmake 生成器去支持啓動工程設置
  • #605: 改進 add_deps 和 add_packages 直接的導出 links 順序
  • 移除廢棄的 add_defines_h_if_ok and add_defines_h 接口

Bugs 修復

  • #1219: 修復版本檢測和更新
  • #1235: 修復 includes 搜索路徑中帶有空格編譯不過問題
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程