Xmake v2.6.6がリリースされ、分散コンパイルとキャッシュのサポート

Xmake は、Luaをベースにした軽量のクロスプラットフォームビルドツールです。

非常に軽量で、Luaランタイムが組み込まれているため、依存関係はありません。

xmake.luaを使用してプロジェクトの構築を維持します。makefile/CMakeLists.txtと比較して、構成構文はより簡潔で直感的で、初心者にとって非常に使いやすいです。短時間ですばやく開始できるため、ユーザーはより多くのことに集中できます。実際のプロジェクト開発について。

これを使用して、Make / Ninjaのようにプロジェクトを直接コンパイルしたり、CMake / Mesonのようにプロジェクトファイルを生成したりできます。さらに、ユーザーがC /C++依存ライブラリの統合使用を解決するのに役立つパッケージ管理システムが組み込まれています。

現在、Xmakeは主にC / C ++プロジェクトの構築に使用されていますが、C / C ++との混合コンパイルを実現できる他のネイティブ言語の構築もサポートしており、コンパイル速度も非常に高速で、同等です。忍者へ。

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

あまり正確ではありませんが、Xmakeは次のように理解できます。

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

新機能の紹介

このリリースでは、大量の新機能が追加されました。

  • 分散コンパイルのサポート
  • 組み込みのローカルコンパイルキャッシュ
  • リモートコンパイルキャッシュのサポート

これらの機能を使用すると、大規模なC /C++プロジェクトをはるかに高速にコンパイルできます。さらに、それらは完全にクロスプラットフォームであり、gcc / clangだけでなくmsvcもサポートし、非常に使いやすいコンパイラ以外にサードパーティの依存関係はありません。

したがって、Xmakeを使用することは、同時に使用することと同じです。 distcc/ccache/sccache

これらのサードパーティツールと比較して、XmakeはWindowsとmsvcを完全にサポートしているため、プラットフォームの違い、独立したプロセス呼び出し、および追加のデーモンプロセスのオーバーヘッドが排除されます。

これらの機能に加えて、Xmakeの新しいバージョンでは、Keil / c51プロジェクトのコンパイルサポート、およびnvidia-hpc-sdkツールチェーンのnvc / nvc ++/nvfortranコンパイラのサポートも追加されています。

リモートコンパイルはユーザー認証をサポートします

前回のバージョンでは、当初はリモートコンパイルをサポートしていましたが、セキュリティ上の問題が発生する可能性のあるユーザー認証サポートを提供していなかったため、このバージョンではユーザー認証サポートを追加しました。

現在、Xmakeは主に以下の認証メカニズムを提供しており、分散コンパイルやリモートキャッシングにも有効です。

  1. トークン認証
  2. パスワード認証
  3. 信頼できるホストの検証

トークン認証

これは、デフォルトで推奨される方法でもあり、より安全で、構成と接続がより便利であり、接続するたびにパスワードを入力する必要がありません。

コマンドを実行すると、サーバーとクライアントの構成ファイルがデフォルトで生成され、デフォルトのトークンが自動的に生成されるため、ローカル直接接続では構成は必要ありません。 xmake service 

サーバー認証の構成

サーバーは、異なるユーザーホストへの接続を承認するために複数のトークンで構成でき、もちろん1つのトークンを共有できます。

$ cat ~/.xmake/service/server.conf
{
    known_hosts = { },
    logfile = "/Users/ruki/.xmake/service/server/logs.txt",
    remote_build = {
        listen = "0.0.0.0:9691",
        workdir = "/Users/ruki/.xmake/service/server/remote_build"
    },
    tokens = {
        "e438d816c95958667747c318f1532c0f"
    }
}

クライアント認証の構成

クライアントは、サーバー上のトークンを対応するクライアント構成に追加するだけで済みます。

$ cat ~/.xmake/service/client.conf
{
    remote_build = {
        connect = "127.0.0.1:9691",
        token = "e438d816c95958667747c318f1532c0f"
    }
}

新しいトークンを手動で生成する

次のコマンドを実行して、新しいトークンを手動で生成し、それをサーバー構成に追加することもできます。

$ xmake service --gen-token
New token a7b9fc2d3bfca1472aabc38bb5f5d612 is generated!

パスワード認証

また、パスワード認証の認証モードも提供しています。トークン認証と比較して、ユーザーは接続するたびにパスワードを入力する必要があり、検証に合格した後にのみ接続できます。

サーバー認証の構成

パスワード認証の場合、トークンを手動で構成する必要はありません。次のコマンドを実行してユーザーを追加するだけです。追加プロセス中に、ユーザーはパスワードの入力を求められます。

$ xmake service --add-user=ruki
Please input user ruki password:
123456
Add user ruki ok!

次に、xmakeはユーザー名とパスワードを使用して新しいトークンを生成し、サーバーによって構成されたトークンリストに追加します。

$ cat ~/.xmake/service/server.conf
{
    known_hosts = { },
    logfile = "/Users/ruki/.xmake/service/server/logs.txt",
    remote_build = {
        listen = "0.0.0.0:9691",
        workdir = "/Users/ruki/.xmake/service/server/remote_build"
    },
    tokens = {
        "e438d816c95958667747c318f1532c0f",
        "7889e25402413e93fd37395a636bf942"
    }
}

もちろん、指定したユーザーとパスワードを削除することもできます。

$xmake service --rm-user=ruki
Please input user ruki password:
123456
Remove user ruki ok!

クライアント認証の構成

クライアントの場合、サーバーのトークンを設定する必要はありません。接続構成で接続する必要のあるユーザー名を追加するだけで、パスワード認証を有効にできます。形式は次のとおりです。user@address:port

$ cat ~/.xmake/service/client.conf
{
    remote_build = {
        connect = "[email protected]:9691"
  }
}

!>ユーザー名が削除され、トークンが構成されていない場合、匿名モードになります。サーバーがトークンで構成されていない場合、認証は完全に無効になり、直接接続されます。

信頼できるホストの検証

さらに、セキュリティをさらに向上させるために、サーバー側の信頼できるホストの検証も提供します。接続可能なクライアントホストのIPアドレスがサーバー構成のknown_hostsリストに構成されている場合、これらのホストのみが正常に接続できます。トークンとパスワードの認証に問題がない場合でも、サーバーと他のホストのサーバーへの接続は信頼できないものとしてプロンプトが表示され、接続を拒否します。

$ cat ~/.xmake/service/server.conf
{
    logfile = "/Users/ruki/.xmake/service/logs.txt",
    server = {
        tokens = {
            "4b928c7563a0cba10ff4c3f5ca0c8e24"
        },
        known_hosts = { "127.0.0.1", "xx.xx.xx.xx"}
    }
}

リモートサーバーに接続する

次に、リモートでコンパイルする必要があるプロジェクトのルートディレクトリを入力し、コマンドを実行して接続するだけです。 xmake service --connect 

トークン認証モードの場合、追加のパスワード入力は不要で、接続は直接接続されます。

$ xmake create test
$ cd test
$ xmake service --connect
<remote_build_client>: connect 192.168.56.110:9091 ..
<remote_build_client>: connected!
<remote_build_client>: sync files in 192.168.56.110:9091 ..
Scanning files ..
Comparing 3 files ..
    [+]: src/main.cpp
    [+]: .gitignore
    [+]: xmake.lua
3 files has been changed!
Archiving files ..
Uploading files with 1372 bytes ..
<remote_build_client>: sync files ok!

パスワード認証の場合、ユーザーは接続を続行するためにパスワードを入力するように求められます。

$ xmake service --connect
Please input user root password:
000000
<remote_build_client>: connect 127.0.0.1:9691 ..
<remote_build_client>: connected!
<remote_build_client>: sync files in 127.0.0.1:9691 ..
Scanning files ..
Comparing 3 files ..
    [+]: xmake.lua
    [+]: .gitignore
    [+]: src/main.cpp
3 files has been changed!
Archiving files ..
Uploading files with 1591 bytes ..
<remote_build_client>: sync files ok!

パスワードが間違っていると、エラーメッセージが表示されます。

$ xmake service --connect
Please input user root password:
123
<remote_build_client>: connect 127.0.0.1:9691 ..
<remote_build_client>: connect 127.0.0.1:9691 failed, user and password are incorrect!

分散コンパイルのサポート

Xmakeは、組み込みの分散コンパイルサービスを提供します。通常、ローカルコンパイルキャッシュおよびリモートコンパイルキャッシュと連携して、最適なコンパイルアクセラレーションを実現できます。

また、完全にクロスプラットフォームでサポートされており、gcc / clangだけでなく、Windowsとmsvcもサポートしています。

クロスコンパイルは、クロスツールチェーンがサポートしている限り、サーバーのシステム環境は必要ありません。Linux、macOS、Windowsのサーバーリソースが混在していても、分散コンパイルを実現できます。

サービスを開始します

分散コンパイルサービスを有効にするパラメーターを指定できます。もちろん、このパラメーターが指定されていない場合、xmakeはデフォルトですべてのサーバー構成サービスを有効にします。 --distcc 

$ xmake service --distcc
<distcc_build_server>: listening 0.0.0.0:9093 ..

また、サービスを開始し、詳細なログ情報をエコーすることもできます。

$ xmake service --distcc -vD
<distcc_build_server>: listening 0.0.0.0:9093 ..

デーモンモードでサービスを開始します

$ xmake service --distcc --start
$ xmake service --distcc --restart
$ xmake service --distcc --stop

サーバーを構成する

まず、コマンドを実行すると、デフォルトの構成ファイルが自動的に生成され、に保存されます。 xmake service  server.conf  ~/.xmake/service/server.conf

$ xmake service
generating the config file to /Users/ruki/.xmake/service/server.conf ..
an token(590234653af52e91b9e438ed860f1a2b) is generated, we can use this token to connect service.
generating the config file to /Users/ruki/.xmake/service/client.conf ..
<distcc_build_server>: listening 0.0.0.0:9693 ..

次に、それを編集して、サーバーのリスニングポートを修正します(オプション)。

$ cat ~/.xmake/service/server.conf
{
    distcc_build = {
        listen = "0.0.0.0:9693",
        workdir = "/Users/ruki/.xmake/service/server/distcc_build"
    },
    known_hosts = { },
    logfile = "/Users/ruki/.xmake/service/server/logs.txt",
    tokens = {
        "590234653af52e91b9e438ed860f1a2b"
    }
}

クライアントを構成する

クライアント構成ファイルがあり、クライアントが接続する必要のあるサーバーアドレスを構成できます。 ~/.xmake/service/client.conf

ホストリストで複数のサーバーアドレスと対応するトークンを構成できます。

!>分散コンパイルでは、トークン認証モードを使用することをお勧めします。パスワードモードのため、各サーバーは接続時にパスワードを1回入力する必要があり、非常に面倒です。

$cat ~/.xmake/service/client.conf
{
    distcc_build = {
        hosts = {
            {
                connect = "127.0.0.1:9693",
                token = "590234653af52e91b9e438ed860f1a2b"
            }
        }
    }
}

サーバーに接続する

認証とサーバーアドレスを構成した後、次のコマンドを入力して、現在のプロジェクトを構成済みサーバーに接続できます。

接続時に、分散サービスのみが接続されることを指定するように入力する必要があります。 --distcc

$ cd projectdir
$ xmake service --connect --distcc
<client>: connect 127.0.0.1:9693 ..
<client>: 127.0.0.1:9693 connected!

分散コンパイルやリモートコンパイルキャッシュサービスなど、複数のサービスに同時に接続することもできます。

$ xmake service --connect --distcc --ccache

!>パラメータがない場合、デフォルトの接続はリモートコンパイルサービスです。

分散コンパイルプロジェクト

サーバーに接続した後、通常のローカルコンパイルのように分散コンパイルを実行できます。次に例を示します。

$ xmake
...
[ 93%]: ccache compiling.release src/demo/network/unix_echo_client.c         ----> local job
[ 93%]: ccache compiling.release src/demo/network/ipv6.c
[ 93%]: ccache compiling.release src/demo/network/ping.c
[ 93%]: distcc compiling.release src/demo/network/unix_echo_server.c.         ----> distcc job
[ 93%]: distcc compiling.release src/demo/network/http.c
[ 93%]: distcc compiling.release src/demo/network/unixaddr.c
[ 93%]: distcc compiling.release src/demo/network/ipv4.c
[ 94%]: distcc compiling.release src/demo/network/ipaddr.c
[ 94%]: distcc compiling.release src/demo/math/fixed.c
[ 94%]: distcc compiling.release src/demo/libm/float.c
[ 95%]: ccache compiling.release src/demo/libm/double.c
[ 95%]: ccache compiling.release src/demo/other/test.cpp
[ 98%]: archiving.release libtbox.a
[ 99%]: linking.release demo
[100%]: build ok!

その中で、distccを含む単語はリモートコンパイルタスクであり、その他はローカルコンパイルタスクです。デフォルトでは、xmakeはローカルコンパイルキャッシュを有効にして分散コンパイル結果をキャッシュし、サーバーへの頻繁な要求を回避します。

さらに、リモートコンパイルキャッシュを開き、コンパイルキャッシュを他のユーザーと共有して、複数のユーザーによる共同開発のコンパイルをさらに高速化することもできます。

切断する

$ xmake service --disconnect --distcc

並列コンパイルタスクの数を指定します

ホストCPUコアの数に基づいてデフォルトで現在計算されている並列タスクの数を簡単に紹介します。

local default_njob = math.ceil(ncpu * 3 / 2)

したがって、分散コンパイルが有効になっていない場合、並列コンパイルタスクのデフォルトの最大数はこのdefault_njobです。

分散コンパイルが有効になっている場合、並列コンパイルタスクのデフォルト数は次のとおりです。

local maxjobs = default_njob + server_count * server_default_njob

ローカル並列タスクの数を変更する

ローカル並列タスクの数は、渡すだけで指定できますが、サーバー側の並列タスクの数には影響しません。 -jN 

$ xmake -jN

サーバー上の並列タスクの数を変更します

サーバー上の並列タスクの数を変更する場合は、クライアントの構成ファイルを変更する必要があります。

$cat ~/.xmake/service/client.conf
{
    distcc_build = {
        hosts = {
            {
                connect = "127.0.0.1:9693",
                token = "590234653af52e91b9e438ed860f1a2b",
                njob = 8   <------- modify here
            },
            {
                connect = "192.168.01:9693",
                token = "590234653af52e91b9e438ed860f1a2b",
                njob = 4
            }
        }
    }
}

サーバーホストごとに、このサーバーが提供できる並列タスクの数を指定するパラメーター構成を追加します。 njob = N 

Androidプロジェクトの分散コンパイル

xmakeが提供する分散コンパイルサービスは完全にクロスプラットフォームであり、Windows、Linux、macOS、Android、iOS、さらにはクロスコンパイルもサポートしています。

Androidプロジェクトをコンパイルする場合は、サーバー構成にツールチェーン構成を追加し、NDKパスを指定するだけで済みます。 toolchains 

$ cat ~/.xmake/service/server.conf
{
    distcc_build = {
        listen = "0.0.0.0:9693",
        toolchains = {
            ndk = {
                ndk = "~/files/android-ndk-r21e"   <------------ here
            }
        },
        workdir = "/Users/ruki/.xmake/service/server/distcc_build"
    },
    known_hosts = { },
    logfile = "/Users/ruki/.xmake/service/server/logs.txt",
    tokens = {
        "590234653af52e91b9e438ed860f1a2b"
    }
}

次に、Androidプロジェクトを通常のローカルコンパイルのように分散してコンパイルし、複数のWindows、macOS、Linux、およびその他の異なるサーバーホストを分散コンパイルサービスのリソースとして構成してコンパイルすることもできます。

対応するプラットフォームのNDKをダウンロードするだけです。

$ xmake f -p android --ndk=~/files/xxxx
$ xmake

iOSプロジェクトの分散コンパイル

Xmakeは通常Xcodeを自動的に検出できるため、iOSプロジェクトのコンパイルは簡単です。そのため、プラットフォームを通常のローカルのようにiosに切り替えるだけです。

$ xmake f -p iphoneos
$ xmake

分散クロスコンパイル構成

クロスコンパイルを配布する場合は、サーバー側でツールチェーンのSDKパスを構成する必要があります。次に例を示します。

$ cat ~/.xmake/service/server.conf
{
    distcc_build = {
        listen = "0.0.0.0:9693",
        toolchains = {
            cross = {
                sdkdir = "~/files/arm-linux-xxx"   <------------ here
            }
        },
        workdir = "/Users/ruki/.xmake/service/server/distcc_build"
    },
    known_hosts = { },
    logfile = "/Users/ruki/.xmake/service/server/logs.txt",
    tokens = {
        "590234653af52e91b9e438ed860f1a2b"
    }
}

その中で、ツールチェーンの下で、各アイテムはツールチェーンに対応します。ツールチェーンは、ここではクロスツールチェーンとして構成されています cross = {}  toolchain("cross")

ツールチェーンではに対応する、など構成できます。またの他のインターフェイス構成も構成できます。 sdkdir bindir cross  toolchain("cross")  set_sdkdir set_bindir  set_cross 

クロスツールチェーンがより標準化されている場合、通常は構成するだけで済み、xmakeはそれを自動的に検出できます。 sdkdir

クライアント側のコンパイルでは、sdkディレクトリを指定するだけで済みます。

$ xmake f -p cross --sdk=/xxx/arm-linux-xxx
$ xmake

サーバーキャッシュをクリアする

サーバー側で各プロジェクトをコンパイルすると、いくつかのキャッシュファイルが生成され、プロジェクトの粒度に従って保存されます。次のコマンドを使用して、現在のプロジェクトの各サーバーに対応するキャッシュをクリアできます。

$ xmake service --clean --distcc

いくつかの内部最適化

  1. サーバー側のコンパイル結果をキャッシュして、コンパイルの繰り返しを回避します
  2. ローカルキャッシュ、リモートキャッシュの最適化、不要なサーバー通信の回避
  3. サーバーの負荷分散のスケジューリング、サーバーリソースの合理的な割り当て
  4. 小さなファイルは、前処理後にローカルで直接コンパイルされます。これは通常、より高速です。
  5. lz4高速圧縮に基づく、大きなファイルのリアルタイム圧縮と送信
  6. 内部状態のメンテナンスは、distccなどの独立したツールと比較して、頻繁な独立したプロセスのロードと時間のかかる作業を回避し、デーモンプロセスとの追加の通信を回避します。

ローカルコンパイルキャッシュのサポート

デフォルトでは、Xmakeはローカルキャッシュを有効にします。2.6.5より前のバージョンはデフォルトで外部ccacheを使用し、2.6.6より後のバージョンは組み込みのクロスプラットフォームローカルキャッシュソリューションを提供します。

ccacheなどのサードパーティの独立したプロセスと比較して、xmakeの内部状態のメンテナンスは最適化が容易であり、頻繁な独立したプロセスの読み込みと時間のかかる作業を回避し、デーモンプロセスとの追加の通信を回避します。

さらに、組み込みキャッシュはクロスプラットフォームをより適切にサポートでき、Windowsのmsvcもそれを適切にサポートできますが、ccacheはgcc/clangのみをサポートします。

もちろん、次のコマンドでキャッシュを無効にすることもできます。

$ xmake f --ccache=n

注:組み込みのローカルキャッシュを使用するかどうかに関係なく、構成名は、ccacheツールの名前だけでなく、c /c++ビルドキャッシュを意味します。 --ccache=

他の外部キャッシュツールを引き続き使用する場合は、次の方法で構成することもできます。

$ xmake f --ccache=n --cxx="ccache gcc" --cc="ccache gcc"
$ xmake

リモートコンパイルキャッシュのサポート

ローカルキャッシュに加えて、mozillaのsscacheと同様のリモートキャッシュサービスも提供しています。これが個人的な開発専用である場合、通常は使用されません。

ただし、大規模なプロジェクトを社内の複数の人が共同で開発する場合は、分散コンパイルとローカルキャッシングだけでは不十分です。また、共有するために、コンパイルされたオブジェクトファイルを別のサーバーにキャッシュする必要があります。

このように、他の人が初めてコンパイルする場合でも、毎回分散してコンパイルする必要はなく、リモートからキャッシュを直接プルしてコンパイルを高速化する必要はありません。

さらに、Xmakeが提供するリモートキャッシュサービスは、gcc / clangだけでなく、msvcも含むすべてのプラットフォームでサポートされています。

サービスを開始します

リモートコンパイルキャッシュサービスを有効にするパラメータを指定できます。もちろん、このパラメータが指定されていない場合、xmakeはデフォルトですべてのサーバー構成サービスを有効にします。 --ccache 

$ xmake service --ccache
<remote_cache_server>: listening 0.0.0.0:9092 ..

また、サービスを開始し、詳細なログ情報をエコーすることもできます。

$ xmake service --ccache -vD
<remote_cache_server>: listening 0.0.0.0:9092 ..

デーモンモードでサービスを開始します

$ xmake service --ccache --start
$ xmake service --ccache --restart
$ xmake service --ccache --stop

サーバーを構成する

まず、コマンドを実行すると、デフォルトの構成ファイルが自動的に生成され、に保存されます。 xmake service  server.conf  ~/.xmake/service/server.conf

$ xmake service
generating the config file to /Users/ruki/.xmake/service/server.conf ..
an token(590234653af52e91b9e438ed860f1a2b) is generated, we can use this token to connect service.
generating the config file to /Users/ruki/.xmake/service/client.conf ..
<remote_cache_server>: listening 0.0.0.0:9692 ..

次に、それを編集して、サーバーのリスニングポートを修正します(オプション)。

$ cat ~/.xmake/service/server.conf
{
    distcc_build = {
        listen = "0.0.0.0:9692",
        workdir = "/Users/ruki/.xmake/service/server/remote_cache"
    },
    known_hosts = { },
    logfile = "/Users/ruki/.xmake/service/server/logs.txt",
    tokens = {
        "590234653af52e91b9e438ed860f1a2b"
    }
}

クライアントを構成する

クライアント構成ファイルがあり、クライアントが接続する必要のあるサーバーアドレスを構成できます。 ~/.xmake/service/client.conf

ホストリストで複数のサーバーアドレスと対応するトークンを構成できます。

$cat ~/.xmake/service/client.conf
{
    remote_cache = {
            connect = "127.0.0.1:9692,
            token = "590234653af52e91b9e438ed860f1a2b"
        }
    }
}

サーバーに接続する

認証とサーバーアドレスを構成した後、次のコマンドを入力して、現在のプロジェクトを構成済みサーバーに接続できます。

接続するときは、リモートコンパイルキャッシュサービスのみを接続するように入力して指定する必要があります。 --ccache

$ cd projectdir
$ xmake service --connect --ccache
<client>: connect 127.0.0.1:9692 ..
<client>: 127.0.0.1:9692 connected!

分散コンパイルやリモートコンパイルキャッシュサービスなど、複数のサービスに同時に接続することもできます。

$ xmake service --connect --distcc --ccache

!>パラメータがない場合、デフォルトの接続はリモートコンパイルサービスです。

切断する

$ xmake service --disconnect --ccache

サーバーキャッシュをクリアする

次のコマンドを使用して、現在のプロジェクトに対応するリモートサーバーのキャッシュをクリアすることもできます。

$ xmake service --clean --ccache

また、実行すると、リモートサービスに接続した状態で、すべてのキャッシュも自動的にクリアされます。 xmake clean --all

いくつかの内部最適化

  1. リモートキャッシュのスナップショットをプルし、ブルームフィルター+ lz4を介してローカルに送り返します。これは、キャッシュが存在するかどうかをすばやく判断し、サーバーのキャッシュ情報を頻繁に照会しないようにするために使用されます。
  2. ローカルキャッシュを使用すると、リモートサーバーへの頻繁な要求を回避し、キャッシュをプルできます。
  3. 内部状態のメンテナンスは、sscacheなどの独立したツールと比較して、頻繁な独立したプロセスのロードと時間のかかる作業を回避し、デーモンとの追加の通信を回避します。

Keil/C51エンジニアリングサポート

c51ツールチェーンにバインドするだけで、XmakeはシステムにインストールされているKeil / C51 SDKツールチェーン環境を自動的に検出し、それを使用してコンパイルできます。

target("hello")
    add_rules("c51.binary")
    set_toolchains("c51")
    add_files("src/main.c")

もちろん、ツールチェーンを設定しない場合は、c51ツールチェーンに手動で切り替えることもできます。 set_toolchains("c51")  xmake f --toolchain=c51 

コンテンツを更新する

新機能

  • #2327:nvidia-hpc-sdkツールチェーンでnvc / nvc ++/nvfortranコンパイラをサポート
  • パスインスタンスインターフェイスを追加
  • #2334:lz4圧縮モジュールを追加
  • #2349:keil/c51プロジェクトのサポートを追加
  • #274:クロスプラットフォームの分散コンパイルのサポート
  • ccacheの代わりに組み込みのローカルキャッシュを使用する

向上

  • #2309:リモートコンパイルはユーザー認証の検証をサポートします
  • リモートコンパイルを改善し、lz4圧縮のサポートを追加します

バグの修正

  • パッケージバージョンを選択する際の不均衡なluaスタックによって引き起こされるクラッシュを修正

 

おすすめ

転載: www.oschina.net/news/197355/xmake-2-6-6-released