<output id="qn6qe"></output>

    1. <output id="qn6qe"><tt id="qn6qe"></tt></output>
    2. <strike id="qn6qe"></strike>

      亚洲 日本 欧洲 欧美 视频,日韩中文字幕有码av,一本一道av中文字幕无码,国产线播放免费人成视频播放,人妻少妇偷人无码视频,日夜啪啪一区二区三区,国产尤物精品自在拍视频首页,久热这里只有精品12

      Xmake v2.7.2 發布,更加智能化構建第三方庫

      Xmake 是一個基于 Lua 的輕量級跨平臺構建工具。

      它非常的輕量,沒有任何依賴,因為它內置了 Lua 運行時。

      它使用 xmake.lua 維護項目構建,相比 makefile/CMakeLists.txt,配置語法更加簡潔直觀,對新手非常友好,短時間內就能快速入門,能夠讓用戶把更多的精力集中在實際的項目開發上。

      我們能夠使用它像 Make/Ninja 那樣可以直接編譯項目,也可以像 CMake/Meson 那樣生成工程文件,另外它還有內置的包管理系統來幫助用戶解決 C/C++ 依賴庫的集成使用問題。

      目前,Xmake 主要用于 C/C++ 項目的構建,但是同時也支持其他 native 語言的構建,可以實現跟 C/C++ 進行混合編譯,同時編譯速度也是非常的快,可以跟 Ninja 持平。

      Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache
      

      盡管不是很準確,但我們還是可以把 Xmake 按下面的方式來理解:

      Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache
      

      新特性介紹

      更加智能化構建第三方庫

      在先前的版本中,Xmake 提供了一種 TryBuild 模式,可以在沒有 xmake.lua 的情況下,使用 Xmake 嘗試對 autoconf/cmake/meson 等維護的第三方項目進行直接構建。

      其實,也就是讓 Xmake 檢測到對應的構建系統后,調用 cmake 等命令來實現,但是會幫助用戶簡化配置操作,另外還能對接 xmake 的交叉編譯工具鏈配置。

      但是,這種模式有一定的失敗率,比如以下一些情況,都會可能導致構建失?。?/p>

      1. 項目代碼自身存在缺陷,導致編譯錯誤
      2. 項目代碼不支持當前平臺
      3. 構建腳本存在缺陷
      4. 缺少特定的配置參數
      5. 缺少依賴庫,需要用戶手動安裝
      6. 編譯器版本太低,不支持部分代碼

      而 TryBuild 模式通常處理這些情況,但是在新版本中,我們對 TryBuild 模式引入了一種新的機制,通過復用 xmake-repo 倉庫中的構建腳本,來改進構建邏輯。

      它大概得處理流程是這樣子的:

      1. 在第三方源碼庫目錄執行 xmake 命令
      2. Xmake 獲取目錄名,嘗試解析項目名和版本
      3. 嘗試從 xmake-repo 倉庫匹配現有的包
      4. 如果匹配成功,直接采用包中構建邏輯來構建
      5. 如果沒匹配成功,回退到原來的 TryBuild 邏輯

      這能帶來什么好處呢,如果匹配成功,我們能夠解決上面提到的各種問題。

      即使當前項目源碼不支持指定平臺,或者源碼和構建腳本存在一定的缺陷,Xmake 也能自動打入特定 patch 去修復它,并引入需要的依賴包,確保它肯定能夠一鍵編譯通過。

      我們使用 libjpeg 庫為例,來直觀的感受下。

      首先是下載對應源碼包

      $ wget https://jaist.dl.sourceforge.net/project/libjpeg-turbo/2.1.4/libjpeg-turbo-2.1.4.tar.gz
      $ tar -xvf libjpeg-turbo-2.1.4.tar.gz
      $ cd libjpeg-turbo-2.1.4
      

      然后進入目錄執行 Xmake 命令

      Xmake 如果檢測到是 libjpeg 庫,就會提示用戶,是否作為 libjpeg 2.1.4 來構建。

      ruki-2:libjpeg-turbo-2.1.4 ruki$ xmake
      note: libjpeg-turbo 2.1.4 in xmake-repo found, try building it or you can run `xmake f --trybuild=` to set buildsystem (pass -y or --confirm=y/n/d to skip confirm)?
      please input: y (y/n)
      

      我們按下回車鍵確認繼續構建。

      checking for cmake ... /usr/local/bin/cmake
      /usr/local/bin/cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_SHARED=OFF -DENABLE_STATIC=ON -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DCMAKE_INSTALL_LIBDIR:PATH=lib -DCMAKE_INSTALL_PREFIX=/Users/ruki/.xmake/packages/l/libjpeg-turbo/2.1.4/646b795702e34be89c5745333d052aa2 -G "Unix Makefiles" -DCMAKE_POSITION_INDEPENDENT_CODE=ON /Users/ruki/Downloads/libjpeg-turbo-2.1.4
      -- CMAKE_BUILD_TYPE = Release
      -- VERSION = 2.1.4, BUILD = 20220923
      -- 64-bit build (x86_64)
      -- CMAKE_INSTALL_PREFIX = /Users/ruki/.xmake/packages/l/libjpeg-turbo/2.1.4/646b795702e34be89c5745333d052aa2
      -- CMAKE_INSTALL_BINDIR = bin (/Users/ruki/.xmake/packages/l/libjpeg-turbo/2.1.4/646b795702e34be89c5745333d052aa2/bin)
      -- CMAKE_INSTALL_DATAROOTDIR = share (/Users/ruki/.xmake/packages/l/libjpeg-turbo/2.1.4/646b795702e34be89c5745333d052aa2/share)
      -- CMAKE_INSTALL_DOCDIR = share/doc/libjpeg-turbo (/Users/ruki/.xmake/packages/l/libjpeg-turbo/2.1.4/646b795702e34be89c5745333d052aa2/share/doc/libjpeg-turbo)
      -- CMAKE_INSTALL_INCLUDEDIR = include (/Users/ruki/.xmake/packages/l/libjpeg-turbo/2.1.4/646b795702e34be89c5745333d052aa2/include)
      -- CMAKE_INSTALL_LIBDIR = lib (/Users/ruki/.xmake/packages/l/libjpeg-turbo/2.1.4/646b795702e34be89c5745333d052aa2/lib)
      -- CMAKE_INSTALL_MANDIR = share/man (/Users/ruki/.xmake/packages/l/libjpeg-turbo/2.1.4/646b795702e34be89c5745333d052aa2/share/man)
      -- Shared libraries disabled (ENABLE_SHARED = 0)
      -- Static libraries enabled (ENABLE_STATIC = 1)
      -- 12-bit JPEG support disabled (WITH_12BIT = 0)
      -- Arithmetic decoding support enabled (WITH_ARITH_DEC = 1)
      -- Arithmetic encoding support enabled (WITH_ARITH_ENC = 1)
      -- TurboJPEG API library enabled (WITH_TURBOJPEG = 1)
      -- TurboJPEG Java wrapper disabled (WITH_JAVA = 0)
      -- In-memory source/destination managers enabled (WITH_MEM_SRCDST = 1)
      -- Emulating libjpeg API/ABI v6.2 (WITH_JPEG7 = 0, WITH_JPEG8 = 0)
      -- libjpeg API shared library version = 62.3.0
      -- Compiler flags =  -O3 -DNDEBUG
      -- Linker flags =
      -- INLINE = __inline__ __attribute__((always_inline)) (FORCE_INLINE = 1)
      -- THREAD_LOCAL = __thread
      -- CMAKE_EXECUTABLE_SUFFIX =
      -- CMAKE_ASM_NASM_COMPILER = /usr/local/bin/nasm
      -- CMAKE_ASM_NASM_OBJECT_FORMAT = macho64
      -- CMAKE_ASM_NASM_FLAGS =  -DMACHO -D__x86_64__ -DPIC
      -- SIMD extensions: x86_64 (WITH_SIMD = 1)
      -- FLOATTEST = sse
      -- Configuring done
      -- Generating done
      -- Build files have been written to: /Users/ruki/Downloads/libjpeg-turbo-2.1.4/build_646b7957
      make -j10
      [  2%] Built target md5cmp
      [ 19%] Built target wrjpgcom
      [ 20%] Built target simd
      [ 21%] Built target strtest
      [ 22%] Built target rdjpgcom
      [ 80%] Built target jpeg-static
      [ 84%] Built target turbojpeg-static
      [ 90%] Built target tjbench-static
      [ 90%] Built target tjunittest-static
      [ 91%] Built target jpegtran-static
      [ 98%] Built target djpeg-static
      [100%] Built target cjpeg-static
      make install
      [  1%] Built target strtest
      [  3%] Built target wrjpgcom
      [ 19%] Built target simd
      [ 52%] Built target turbojpeg-static
      [ 53%] Built target rdjpgcom
      [ 82%] Built target jpeg-static
      [ 85%] Built target jpegtran-static
      [ 90%] Built target djpeg-static
      [ 93%] Built target tjunittest-static
      [ 97%] Built target cjpeg-static
      [ 98%] Built target tjbench-static
      [100%] Built target md5cmp
      Install the project...
      exporting libjpeg-turbo-2.1.4
        -> /Users/ruki/Downloads/libjpeg-turbo-2.1.4/build/artifacts/l/libjpeg-turbo/2.1.4/646b795702e34be89c5745333d052aa2
      output to /Users/ruki/Downloads/libjpeg-turbo-2.1.4/build/artifacts
      build ok!
      

      只要檢測匹配成功,通??隙軌蛲瓿删幾g,成功率接近 100%,最后 Xmake 會將編譯產物輸出到當前目錄的 build/artifacts 下面。

      對接交叉編譯工具鏈

      這種智能構建模式,我們不僅能夠編譯本機程序,還可以對接交叉編譯工具鏈,實現對 ios/android 以及任意交叉編譯平臺的支持。

      例如,編譯 Android 平臺,我們只需要傳遞 --trybuild=xrepo 參數,然后切換到 android 平臺即可,Xmake 會透傳所有 ndk 工具鏈信息。

      $ xmake f -p android --trybuild=xrepo --ndk=~/files/android-ndk-r20b -c
      $ xmake
      xmake f -c --require=n -v -p android -a armeabi-v7a -m release -k static --ndk=/Users/ruki/files/android-ndk-r20b
      checking for Android SDK directory ... ~/Library/Android/sdk
      checking for Build Tools Version of Android SDK ... 33.0.0
      checking for NDK directory ... /Users/ruki/files/android-ndk-r20b
      checking for SDK version of NDK ... 21
      checking for clang++ ... /Users/ruki/files/android-ndk-r20b/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
      checking for the shared library linker (sh) ... clang++
      checking for clang++ ... /Users/ruki/files/android-ndk-r20b/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
      checking for the linker (ld) ... clang++
      ...
      exporting libjpeg-turbo-2.1.4
        -> /Users/ruki/Downloads/libjpeg-turbo-2.1.4/build/artifacts/l/libjpeg-turbo/2.1.4/79c2e21f436b4ab08a3c23a6cbae8c0e
      output to /Users/ruki/Downloads/libjpeg-turbo-2.1.4/build/artifacts
      build ok!
      

      回退到直接編譯

      如果我們不想使用 xmake-repo 的構建腳本,我們也能回退到 cmake/autoconf 直接去嘗試構建它們。

      但是這樣可能會存在一定的失敗率,并且有可能會額外編譯一些不需要的二進制目標。而 xmake-repo 里面的構建腳本是最優化的,精簡了很多沒必要的構建參數,比如禁用 tests/examples 構建等等。

      我們只需要先敲 n 取消基于包腳本的智能構建模式,Xmake 會有新的提示,讓用戶選擇是否繼續采用 cmake/autoconf 來嘗試構建。

      $ xmake
      note: libjpeg-turbo 2.1.4 in xmake-repo found, try building it or you can run `xmake f --trybuild=` to set buildsystem (pass -y or --confirm=y/n/d to skip confirm)?
      please input: y (y/n)
      n
      note: CMakeLists.txt found, try building it or you can run `xmake f --trybuild=` to set buildsystem (pass -y or --confirm=y/n/d to skip confirm)?
      please input: y (y/n)
      

      支持 Windows Arm64

      新版本我們還對 Windows 的構建支持做了改進,新增了 Windows Arm64 平臺支持,只需要切換到 arm64 架構即可。

      $ xmake f -a arm64
      $ xmake
      

      改進規則支持依賴順序執行

      關聯依賴可以綁定一批規則,也就是不必對 target 挨個去使用 add_rules() 添加規則,只需要應用一個規則,就能生效它和它的所有依賴規則。

      例如:

      rule("foo")
          add_deps("bar")
      
      rule("bar")
         ...
      

      我們只需要 add_rules("foo"),就能同時應用 foo 和 bar 兩個規則。

      但是,默認情況下,依賴之間是不存在執行的先后順序的,foo 和 bar 的 on_build_file 等腳本是并行執行的,順序未定義。

      如果要嚴格控制執行順序,在新版本中,我們可以配置 add_deps("bar", {order = true}),告訴 xmake,我們需要根據依賴順序來執行同級別的腳本。

      例如:

      rule("foo")
          add_deps("bar", {order = true})
          on_build_file(function (target, sourcefile)
          end)
      
      rule("bar")
          on_build_file(function (target, sourcefile)
          end)
      

      bar 的 on_build_file 將會被先執行。

      更好的動態配置目標和規則

      上面這種控制規則依賴的方式,只適合 foo 和 bar 兩個規則都是自定義規則,如果想要將自己的規則插入到 xmake 的內置規則之前執行,這就不適用了。

      這個時候,我們需要使用更加靈活的動態規則創建和注入的方式,去修改內置規則。

      例如,我們想在內置的 c++.build 規則之前,執行自定義 cppfront 規則的 on_build_file 腳本,我們可以通過下面的方式來實現。

      rule("cppfront")
          set_extensions(".cpp2")
          on_load(function (target)
              local rule = target:rule("c++.build"):clone()
              rule:add("deps", "cppfront", {order = true})
              target:rule_add(rule)
          end)
          on_build_file(function (target, sourcefile, opt)
              print("build cppfront file")
          end)
      
      target("test")
          set_kind("binary")
          add_rules("cppfront")
          add_files("src/*.cpp")
          add_files("src/*.cpp2")
      

      支持從包中引入自定義規則

      現在,我們還可以在包管理倉庫中,添加自定義構架規則腳本,實現跟隨包進行動態下發和安裝。

      我們需要將自定義規則放到倉庫的 packages/x/xxx/rules 目錄中,它會跟隨包一起被安裝。

      當然,它也存在一些限制:

      • 在包中規則,我們不能添加 on_load, after_load 腳本,但是通常我們可以使用 on_config 來代替。

      添加包規則

      我們需要將規則腳本添加到 rules 固定目錄下,例如:packages/z/zlib/rules/foo.lua

      rule("foo")
          on_config(function (target)
              print("foo: on_config %s", target:name())
          end)
      

      應用包規則

      使用規則的方式跟之前類似,唯一的區別就是,我們需要通過 @packagename/ 前綴去指定訪問哪個包里面的規則。

      具體格式:add_rules("@packagename/rulename"),例如:add_rules("@zlib/foo")

      add_requires("zlib", {system = false})
      target("test")
          set_kind("binary")
          add_files("src/*.cpp")
          add_packages("zlib")
          add_rules("@zlib/foo")
      

      通過包別名引用規則

      如果存在一個包的別名,xmake 將優先考慮包的別名來獲得規則。

      add_requires("zlib", {alias = "zlib2", system = false})
      target("test")
          set_kind("binary")
          add_files("src/*.cpp")
          add_packages("zlib2")
          add_rules("@zlib2/foo")
      

      添加包規則依賴

      我們可以使用add_deps("@bar")來添加相對于當前包目錄的其他規則。

      然而,我們不能添加來自其他包的規則依賴,它們是完全隔離的,我們只能參考用戶項目中由add_requires導入的其他包的規則。

      packages/z/zlib/rules/foo.lua

      rule("foo")
          add_deps("@bar")
          on_config(function (target)
              print("foo: on_config %s", target:name())
          end)
      

      packages/z/zlib/rules/bar.lua

      rule("bar")
          on_config(function (target)
              print("bar: on_config %s", target:name())
          end)
      

      更加嚴格的包依賴兼容性支持

      我們新增了兩個包相關的策略,用于開啟更加嚴格的包依賴兼容性控制。

      這主要用于解決一些包每次版本更新,可能都會存在一些 abi 不兼容,或者破壞其他依賴它的包,而默認 Xmake 是不會去重新編譯安裝它們的,除非它們的版本和配置也被更新了。

      這就可能存在一定概率編譯兼容性被破壞,導致最終鏈接失敗。

      package.librarydeps.strict_compatibility

      默認禁用,如果啟用它,那么當前包和它的所有庫依賴包之間會保持嚴格的兼容性,任何依賴包的版本更新,都會強制觸發當前包的重新編譯安裝。

      以確保所有的包都是二進制兼容的,不會因為某個依賴包接口改動,導致和其他已被安裝的其他包一起鏈接時候,發生鏈接和運行錯誤。

      package("foo")
          add_deps("bar", "zoo")
          set_policy("package.librarydeps.strict_compatibility", true)
      

      例如,如果 bar 或者 zoo 的版本有更新,那么 foo 也會重新編譯安裝。

      package.strict_compatibility

      默認禁用,如果啟用它,那么當前包和其他所有依賴它的包之間會保持嚴格的兼容性,這個包的版本更新,都會強制觸發其他父包的重新編譯安裝。

      以確保所有的包都是二進制兼容的,不會因為某個依賴包接口改動,導致和其他已被安裝的其他包一起鏈接時候,發生鏈接和運行錯誤。

      package("foo")
          set_policy("package.strict_compatibility", true)
      
      package("bar")
          add_deps("foo")
      
      package("zoo")
          add_deps("foo")
      

      例如,如果 foo 的版本有更新,那么 bar 和 zoo 都會被強制重新編譯安裝。

      package.install_always

      每次運行 xmake f -c 重新配置的時候,總是會重新安裝包,這對于本地第三方源碼包集成時候比較有用。

      因為,用戶可能隨時需要修改第三方源碼,然后重新編譯集成它們。

      之前只能通過每次修改包版本號,來觸發重新編譯,但是有了這個策略,就能每次都會觸發重編。

      add_rules("mode.debug", "mode.release")
      
      package("foo")
          add_deps("cmake")
          set_sourcedir(path.join(os.scriptdir(), "foo"))
          set_policy("package.install_always", true)
          on_install(function (package)
              local configs = {}
              table.insert(configs, "-DCMAKE_BUILD_TYPE=" .. (package:debug() and "Debug" or "Release"))
              table.insert(configs, "-DBUILD_SHARED_LIBS=" .. (package:config("shared") and "ON" or "OFF"))
              import("package.tools.cmake").install(package, configs)
          end)
          on_test(function (package)
              assert(package:has_cfuncs("add", {includes = "foo.h"}))
          end)
      package_end()
      
      add_requires("foo")
      
      target("demo")
          set_kind("binary")
          add_files("src/main.c")
          add_packages("foo")
      

      新增 clang-cl 工具鏈

      盡管之前的版本,我們也支持切換到 clang-cl 編譯器,但是切換比較繁瑣,得挨個設置。

      $ xmake f --cxx=clang-cl --cc=clang-cl -c
      $ xmake
      

      而且還得將 clang-cl.exe 所在目錄加入 %PATH% 才行。

      既然現在 vs 都自帶了 clang-cl 工具鏈,那么 Xmake 完全可以自動檢測到并使用它。

      因此,在新版本中,我們新增了 clang-cl 工具鏈,僅僅只需要 xmake f --toolchain=clang-cl 就可以快速切換到 clang-cl 工具鏈,而無需任何 PATH 設置。

      更新內容

      新特性

      • #2140: 支持 Windows Arm64
      • #2719: 添加 package.librarydeps.strict_compatibility 策略嚴格限制包依賴兼容性
      • #2810: 支持 os.execv 去執行 shell 腳本文件
      • #2817: 改進規則支持依賴順序執行
      • #2824: 傳遞 cross-file 交叉編譯環境給 meson.install 和 trybuild
      • #2856: xrepo 支持從當前指定源碼目錄調試程序
      • #2859: 改進對三方庫的 trybuild 構建,利用 xmake-repo 倉庫腳本更加智能化地構建三方庫
      • #2879: 更好的動態創建和配置 target 和 rule
      • #2374: 允許 xmake 包中引入自定義規則
      • 添加 clang-cl 工具鏈

      改進

      • #2745: 改進 os.cp 支持符號鏈接復制
      • #2773: 改進 vcpkg 包安裝,支持 freebsd 平臺
      • #2778: 改進 xrepo.env 支持 target 的運行環境加載
      • #2783: 添加摘要算法選項到 WDK 的 signtool 簽名工具
      • #2787: 改進 json 支持空數組
      • #2782: 改進查找 matlib sdk 和運行時
      • #2793: 改進 mconfdialog 配置操作體驗
      • #2804: 安裝依賴包支持 macOS arm64/x86_64 交叉編譯
      • #2809: 改進 msvc 的編譯優化選項
      • 改進 trybuild 模式,為 meson/autoconf/cmake 提供更好的交叉編譯支持
      • #2846: 改進對 configfiles 的生成
      • #2866: 更好地控制 rule 規則執行順序

      Bugs 修復

      • #2740: 修復 msvc 構建 C++ modules 卡死問題
      • #2875: 修復構建 linux 驅動錯誤
      • #2885: 修復 ccache 下,msvc 編譯 pch 失敗問題
      posted @ 2022-10-10 17:33  waruqi  Views(249)  Comments(0)    收藏  舉報
      主站蜘蛛池模板: 国产精品亚洲一区二区z| 玩弄丰满少妇人妻视频| 鲁一鲁一鲁一鲁一澡| 一区二区三区激情都市| 亚洲一区二区三区人妻天堂| 昌都县| 日韩午夜一区二区福利视频 | 伊人久久大香线蕉av一区二区| 亚洲一区精品视频在线| 永久天堂网 av手机版| 国产无遮挡猛进猛出免费| 美女爽到高潮嗷嗷嗷叫免费网站| 精品国偷自产在线视频99| 视频一区二区不中文字幕| 久久精品国产亚洲精品2020| 国产激情一区二区三区四区| 丝袜a∨在线一区二区三区不卡| 中文字幕人妻中出制服诱惑| 永久天堂网 av手机版| 蜜臀人妻精品一区二区免费| 欧美和黑人xxxx猛交视频| 国产精品久久中文字幕| 亚洲暴爽av天天爽日日碰| 窝窝午夜色视频国产精品破| 91老肥熟女九色老女人| 亚洲成人网在线观看| 中文字幕亚洲综合久久| 新疆| 老司机午夜精品视频资源| 乱人伦人妻中文字幕不卡| 国内精品伊人久久久久影院对白| 国产精品午夜福利在线观看| 九九热精品免费视频| 青草热在线观看精品视频| 北辰区| 精品国产免费一区二区三区香蕉| 无码精品一区二区免费AV| 亚洲色帝国综合婷婷久久| 伦伦影院午夜理论片| 性色欲情网站| 麻豆麻豆麻豆麻豆麻豆麻豆|