xmakeがクロスコンパイルをより適切にサポートできるようにするために、このバージョンでツールチェーン全体をリファクタリングして、ツールチェーンの切り替えをより便利かつ迅速にしました。これで、ユーザーはxmake.luaでツールチェーンを簡単に拡張できます。
プラットフォームのサポートに関しては、* BSDシステムのサポートが追加されました。さらに、このバージョンでは、忍者に似たコンパイルの進行状況の表示を実現するために、忍者のテーマスタイルも追加されています。
新機能の紹介
ツールチェーンの改善
ツールチェーンとプラットフォームの完全な分離
以前のバージョン、プラットフォーム、およびプラットフォームなどのツールチェーンが緊密にバインドされてxmake f -p windowsいる場合、デフォルトはmsvcのコンパイルにのみ使用でき、カットまたは他のclangコンパイラーが必要であり、クロスコンパイラープラットフォームは次のことしかできませんxmake f -p cross。
ただし、この場合、一部のWindowsプラットフォーム固有の設定が失われ、ユーザーはそれif is_plat("windows") thenを使用してWindowsプラットフォームを判断して特定の設定を行うことができなくなります。
実際、プラットフォームとツールチェーンは完全に独立している可能性があります。新しいバージョンがリファクタリングされた後、Windowsプラットフォームやその他のプラットフォームでさえ、clang、llvmなどの他のツールチェーンに簡単かつ迅速に切り替えることができます。
$ xmake f -p windows --toolchain=clang
組み込みのツールチェーン
クロスコンパイラーはすべてのxmake構成ツールチェーンをサポートし、ある程度のインテリジェンス分析および検出ツールチェーンも提供しますが、一般的な計画では、特定のツールチェーンサポートに多様性を追加するために必要な追加の構成の数を計画します。--ldflags=、--cxflags=パラメータなど。
新しいバージョンのxmakeには、一般的に使用されるツールチェーンがいくつか組み込まれているため、ツールチェーンのクロスコンパイルの複雑な構成プロセスを節約できます。ツールチェーン名を渡すだけで済み--toolchain=xxxます。
llvmツールチェーンに切り替えます。
$ xmake f -p cross --toolchain=llvm --sdk="C:\Program Files\LLVM"
$ xmake
GNU-RMツールチェーンに切り替えます。
$ xmake f -p cross --toolchain=gnu-rm --sdk=/xxx/cc-arm-none-eabi-9-2019-q4-major
$ xmake
指定したクロスコンパイルツールチェーンにすばやく切り替えることができます。組み込みツールチェーンの場合、ほとんどの構成を省略できます。通常、統合のみが必要で--toolchain=あり、--sdk=他の構成は自動的に設定されて、コンパイルが確実に行われるようにします。正常。
xmakeはどの組み込みツールチェーンをサポートしていますか？次のコマンドで表示できます。
$ xmake show -l toolchains
xcode Xcode IDE
vs VisualStudio IDE
yasm The Yasm Modular Assembler
clang A C language family frontend for LLVM
go Go Programming Language Compiler
dlang D Programming Language Compiler
sdcc Small Device C Compiler
cuda CUDA Toolkit
ndk Android NDK
rust Rust Programming Language Compiler
llvm A collection of modular and reusable compiler and toolchain technologies
cross Common cross compilation toolchain
nasm NASM Assembler
gcc GNU Compiler Collection
mingw Minimalist GNU for Windows
gnu-rm GNU Arm Embedded Toolchain
envs Environment variables toolchain
fasm Flat Assembler
ツールチェーンの同期切り替え
新しいバージョンのxmakeは、ツールチェーンの完全な同期切り替えもサポートしています。これはどういう意味ですか？
たとえば、デフォルトのgccからclangコンパイルに切り替える場合xmake f --cc=clang --cxx=clang --ld=clang++ --sh=clang++、コンパイラー、対応するリンカー、静的ライブラリアーカイバ、およびすべてを同時にカットする必要があるため、いくつかのツールセットをカットする必要がある場合があります。
このように1つずつカットするのは本当に苦痛で、作者自身も耐えられないので、ツールチェーンをリファクタリングするときに、この部分も改善され、次のことだけが必要になります。
$ xmake f --toolchain=clang
$ xmake
すべてのclangツールセットを全体として完全にカットできます。gccに戻す方法も非常に便利です。
または
$ xmake f --toolchain=gcc
$ xmake
カスタムツールチェーン
さらに、xmake.luaでツールチェーンをカスタマイズしてから、次のxmake f --toolchain=myclangように指定して切り替えることもできます。
toolchain("myclang")
set_kind("standalone")
set_toolset("cc", "clang")
set_toolset("cxx", "clang", "clang++")
set_toolset("ld", "clang++", "clang")
set_toolset("sh", "clang++", "clang")
set_toolset("ar", "ar")
set_toolset("ex", "ar")
set_toolset("strip", "strip")
set_toolset("mm", "clang")
set_toolset("mxx", "clang", "clang++")
set_toolset("as", "clang")
-- ...
これはset_toolset、コンパイラ、リンカ、アセンブラなどのさまざまなツールセットを設定するために使用されます。
デフォルトでは、xmakeはxmake f --sdk=xxSDKパラメーターからツールを検出します。もちろん、xmake.luaの各カスタムツールチェーンを呼び出しset_sdk("/xxx/llvm")て、ツールチェーンSDKアドレスを書き込むこともできます。
この部分の詳細な紹介については、カスタムツールチェーンの章に移動して表示できます
詳細：＃780
特定のターゲットのツールチェーンを設定する
カスタムツールチェーンに加えて、特定のターゲットの異なるツールチェーンに個別に切り替えることもできます。set_toolsetとは異なり、このインターフェイスは、cc / ld / shセットなどの一連のツールなどの完全なツールチェーンの全体的なスイッチです。
gcc / clang、コンパイラ、リンカなどのコンパイラツールチェーンのほとんどが一緒に使用されるため、これもお勧めします。カットする場合は、全体をカットする必要があり、非常に面倒です。設定を個別に切り替えます。
たとえば、テストターゲットをclang + yasmの2つのツールチェーンに切り替えます。
target("test")
set_kind("binary")
add_files("src/*.c")
set_toolchains("clang", "yasm")
またはset_toolset、各ターゲットのツールチェーンに特定のツールを個別に設定するために使用できます。
target("test")
set_kind("binary")
set_toolset("cxx", "clang")
set_toolset("ld", "clang++")
忍者ビルドテーマ
建設の進行状況は忍者に似ており、1行の進行状況バーがあり、進行状況をロールバックする必要がなくなり、ユーザーは自分の好みに応じて設定できます。
進行状況の表示が異なることを除いて、他のすべてはデフォルトのテーマ構成と同じです。
$ xmake g --theme=ninja
ビルド動作戦略を設定する
Xmakeには、フラグの自動検出とマッピング、クロスターゲット並列構築など、多くのデフォルトの動作があります。ある程度のインテリジェントな処理を提供しますが、調整が難しく、すべてのユーザーの習慣やニーズを満たすとは限りません。
したがって、v2.3.4以降、xmakeはデフォルトのビルド戦略の変更設定を提供します。これは、ある程度の構成可能性をユーザーに公開します。
使用法は次のとおりです。
set_policy("check.auto_ignore_flags", false)
フラグの自動検出および無視メカニズムを無効にするには、プロジェクトルートドメインでこの構成を設定するだけset_policyで済みます。また、特定のターゲットに対してローカルで有効にすることもできます。
target("test")
set_policy("check.auto_ignore_flags", false)
！>さらに、設定されたポリシー名が無効な場合、xmakeも警告を表示します。
xmakeでサポートされているすべてのポリシー構成のリストと説明を取得する場合は、次のコマンドを実行できます。
$ xmake l core.project.policy.policies
{
"check.auto_map_flags" = {
type = "boolean",
description = "Enable map gcc flags to the current compiler and linker automatically.",
default = true
},
"build.across_targets_in_parallel" = {
type = "boolean",
description = "Enable compile the source files for each target in parallel.",
default = true
},
"check.auto_ignore_flags" = {
type = "boolean",
description = "Enable check and ignore unsupported flags automatically.",
default = true
}
}
check.auto_ignore_flags
デフォルトではadd_cxflags、xmakeはadd_ldflagsインターフェイスによって設定されたすべての元のフラグを自動的に検出します。現在のコンパイラとリンカがそれらをサポートしていないことを検出すると、xmakeはそれらを自動的に無視します。
これは通常非常に便利です。たとえば、一部のオプションのコンパイルフラグは、サポートされていなくても正常にコンパイルできますが、強制的に設定されます。他のユーザーがコンパイルしている場合、次の理由である程度のエラーが発生する可能性があります。コンパイラのサポートレベルが異なります。コンパイルに失敗しました。
ただし、自動検出は100％の信頼性を保証するものではなく、ある程度の誤判定が発生する場合があるため、この設定を好まないユーザーもいます（特に、障害が発生しやすいクロスコンパイルツールチェーンの場合）。
現在、v2.3.4バージョンで検出が失敗した場合、ユーザーが不可解にピットに横たわるのを防ぐための警告が表示されます。次に例を示します。
warning: add_ldflags("-static") is ignored, please pass `{
force = true}` or call `set_policy("check.auto_ignore_flags", false)` if you want to set it.
プロンプトに従って、このフラグを強制的に設定する必要があるかどうかを自分で分析および判断できます。1つは合格です。
add_ldflags("-static", {force = true})
必須設定を表示するには、自動検出をスキップします。これは、たまに発生するフラグの失敗に対処するための非常に効果的で迅速な方法ですが、クロスコンパイルの場合、多数のフラグが検出されない場合、それぞれが力を設定するのは面倒です。
現時点でset_policyは、ターゲットまたはプロジェクト全体のデフォルトの自動検出動作を直接無効にすることができます。
set_policy("check.auto_ignore_flags", false)
target("test")
add_ldflags("-static")
次に、さまざまな元のフラグを自由に設定できます。xmakeはそれらを自動的に検出して無視しません。
check.auto_map_flags
これは、xmakeによるフラグのもう1つのインテリジェントな分析と処理です。通常add_links、add_definesxmakeの組み込みAPIによって設定される構成はクロスプラットフォームです。異なるコンパイラプラットフォームは、対応する元のフラグを自動的に処理します。
ただし、場合によっては、ユーザーはadd_cxflags、add_ldflagsを介して元のコンパイルリンクフラグを設定する必要があり、これらのフラグはコンパイラー間でうまくクロスできません。
-O0例としてコンパイル最適化フラグを取り上げます。set_optimizeクロスコンパイラ構成がありますが、ユーザーがそれらを直接設定するとどうなりますadd_cxflags("-O0")か？gcc / clangでは通常どおり処理できますが、msvcではサポートされていません。
if is_plat() thenプラットフォームで処理できるかもしれませんが、非常に面倒なので、xmakeにはフラグの自動マッピング機能が組み込まれています。
gccフラグの人気に基づいて、xmakeはgccフラグの命名規則を使用して、さまざまなコンパイルに従って自動的にマップします。次に例を示します。
add_cxflags("-O0")
この行設定はまだgcc / clangの下にありますが-O0、現在のmsvcコンパイラーが使用されている-Od場合、最適化を無効にするために、msvc対応するコンパイラーオプションに自動的にマップされます。
プロセス全体を通して、ユーザーは完全に気付かず、xmakeを直接実行することでクロスコンパイラーを完了することができます。
！>もちろん、現在の自動マッピングの実装はあまり成熟しておらず、すべてのgccフラグを100％カバーしているわけではないため、マッピングされていないフラグがまだたくさんあります。
一部のユーザーはこの自動マッピング動作を好まないため、次の設定を使用してこのデフォルトの動作を完全に無効にすることができます。
set_policy("check.auto_map_flags", false)
build.across_targets_in_parallel
この戦略はデフォルトでも有効になっています。主にターゲット間で並列ビルドを実行するために使用されます。v2.3.3より前のバージョンでは、並列ビルドは単一のターゲット内のすべてのソースファイルのみをターゲットにできます。
クロスターゲットコンパイルの場合は、前のコンパイルを待つ必要があります。完了するターゲットリンクが成功した場合にのみ、次のターゲットのコンパイルを実行できます。これは、コンパイル速度にある程度影響します。
ただし、各ターゲットのソースファイルは完全に並行して処理でき、最後にリンクプロセスが一緒に実行されます。v2.3.3以降のバージョンはこの最適化に合格し、ビルド速度が30％向上しました。
もちろん、一部の特別なターゲットのビルドソースファイルが前のターゲットに依存している場合（特にカスタムルールの場合、めったに発生しませんが）、次の設定を使用してこの最適化動作を無効にすることもできます。
set_policy("build.across_targets_in_parallel", false)
新しいコンパイルモード
mode.releasedbg
現在のプロジェクトxmake.luaのreleasedBgコンパイルモードの構成ルールを追加します。次に例を示します。
add_rules("mode.releasedbg")
！>リリースモードと比較すると、このモードでは追加のデバッグシンボルも有効になり、通常は非常に便利です。
と同等です：
if is_mode("releasedbg") then
set_symbols("debug")
set_optimize("fastest")
set_strip("all")
end
xmake f -m releasedbgこのコンパイルモードに切り替えるには、次の方法があります。
mode.minsizerel
minsizerelコンパイルモードの構成ルールを現在のプロジェクトxmake.luaに追加します。次に例を示します。
add_rules("mode.minsizerel")
！>リリースモードと比較して、このモードは速度の優先順位ではなく、最小限のコードコンパイルの最適化に傾いています。
と同等です：
if is_mode("minsizerel") then
set_symbols("hidden")
set_optimize("smallest")
set_strip("all")
end
xmake f -m minsizerelこのコンパイルモードに切り替えるには、次の方法があります。
指定した情報とリストを表示する
xmake自体と現在のプロジェクトの基本情報を表示します
$ xmake show
The information of xmake:
version: 2.3.3+202006011009
host: macosx/x86_64
programdir: /Users/ruki/.local/share/xmake
programfile: /Users/ruki/.local/bin/xmake
globaldir: /Users/ruki/.xmake
tmpdir: /var/folders/32/w9cz0y_14hs19lkbs6v6_fm80000gn/T/.xmake501/200603
workingdir: /Users/ruki/projects/personal/tbox
packagedir: /Users/ruki/.xmake/packages
packagedir(cache): /Users/ruki/.xmake/cache/packages/2006
The information of project: tbox
version: 1.6.5
plat: macosx
arch: x86_64
mode: release
buildir: build
configdir: /Users/ruki/projects/personal/tbox/.xmake/macosx/x86_64
projectdir: /Users/ruki/projects/personal/tbox
projectfile: /Users/ruki/projects/personal/tbox/xmake.lua
ツールチェーンリストを表示する
$ xmake show -l toolchains
xcode Xcode IDE
vs VisualStudio IDE
yasm The Yasm Modular Assembler
clang A C language family frontend for LLVM
...
指定したターゲット構成情報を表示します
$ xmake show --target=tbox
The information of target(tbox):
kind: static
targetfile: build/macosx/x86_64/release/libtbox.a
rules: mode.release, mode.debug, mode.profile, mode.coverage
options: info, float, wchar, exception, force-utf8, deprecated, xml, zip, hash, regex, coroutine, object, charset, database
packages: mbedtls, polarssl, openssl, pcre2, pcre, zlib, mysql, sqlite3
links: pthread
syslinks: pthread, dl, m, c
cxflags: -Wno-error=deprecated-declarations, -fno-strict-aliasing, -Wno-error=expansion-to-defined, -fno-stack-protector
defines: __tb_small__, __tb_prefix__="tbox"
mxflags: -Wno-error=deprecated-declarations, -fno-strict-aliasing, -Wno-error=expansion-to-defined
headerfiles: src/(tbox/**.h)|**/impl/**.h, src/(tbox/prefix/**/prefix.S), src/(tbox/math/impl/*.h), src/(tbox/utils/impl/*.h), build/macosx/x86_64/release/tbox.config.h
includedirs: src, build/macosx/x86_64/release
at: /Users/ruki/projects/personal/tbox/src/tbox/xmake.lua
sourcebatch(cc): with rule(c.build)
-> src/tbox/string/static_string.c
-> build/.objs/tbox/macosx/x86_64/release/src/tbox/string/static_string.c.o
-> build/.deps/tbox/macosx/x86_64/release/src/tbox/string/static_string.c.o.d
-> src/tbox/platform/sched.c
-> build/.objs/tbox/macosx/x86_64/release/src/tbox/platform/sched.c.o
-> build/.deps/tbox/macosx/x86_64/release/src/tbox/platform/sched.c.o.d
-> src/tbox/stream/stream.c
-> build/.objs/tbox/macosx/x86_64/release/src/tbox/stream/stream.c.o
-> build/.deps/tbox/macosx/x86_64/release/src/tbox/stream/stream.c.o.d
-> src/tbox/utils/base32.c
-> build/.objs/tbox/macosx/x86_64/release/src/tbox/utils/base32.c.o
-> build/.deps/tbox/macosx/x86_64/release/src/tbox/utils/base32.c.o.d
組み込みのコンパイルモードのリストを表示する
$ xmake show -l modes
組み込みのコンパイルルールのリストを表示する
$ xmake show -l rules
その他の情報を表示する
まだ改善中です。詳細については、https：//github.com/xmake-io/xmake/issues/798をご覧ください。
または実行：
$ xmake show --help
コンテンツを更新する
新機能
- ＃630：* BSDシステムをサポートします。例：FreeBSD、…
- 警告メッセージを表示するwprintインターフェースを追加
- ＃784：次の
set_policy()ようないくつかの組み込みポリシーを変更するために追加：自動フラグ検出とマッピングを無効にする - ＃780：ターゲットにset_toolchains / set_toolsetsを追加して、より完全なツールチェーン設定を実現し、プラットフォームとツールチェーンの分離を実現します
- ＃798：
xmake showプラグインを追加してxmakeに組み込まれているさまざまな情報を表示する - ＃797：忍者テーマスタイルを追加し、忍者スタイルの建設プログレスバーを表示し、
xmake g --theme=ninja - ＃816：mode.releasedbgおよびmode.minsizerelコンパイルモードルールを追加
- ＃819：ansi / vt100端末文字制御をサポート
改善する
- ＃771：includedirs、linkdirs、frameworkdirsの入力の有効性を確認してください
- ＃774：
xmake f --menuビジュアル設定メニューはウィンドウサイズのサイズ変更調整をサポートしています - ＃782：add_cxflagsおよびその他の構成フラグの自動検出失敗プロンプトを追加
- ＃808：add_frameworksのサポートを追加するためのcmakelistsプラグインを生成します
- ＃820：独立した作業ディレクトリとビルドディレクトリをサポートし、プロジェクトディレクトリを完全にクリーンに保つ