Godot: ビルドシステムをMesonまたは別のビルドシステムに移動することを検討してください

私が理解していることとして、ビルドシステムツールは以下を提供する必要があります。

• クロスコンパイル（同じホストプラットフォームからすべての可能なターゲットプラットフォームにコンパイルします）。
  
  
  
  • 「可能」とは、ホストがそれを許可していることを意味します（したがって、macOSとiOSはMacマシンでのみ可能であり、LinuxとOSXCrossからのみ可能です）。
  
  
• ファイルを生成する方法（POからの変換、GLSLからのシェーダークラス、XMLからのドキュメントデータ）。
  
  
  
  • SConsは、生成されたファイルが依存関係であることを認識しているため、それらを変更すると、関連するファイルの再構築がトリガーされます。 これも考慮する必要があります。
  
  
• 複数のターゲットとターゲット内のオプション（target = debug / release_debug / release、x86またはARMとしてのアーキテクチャ、32ビットまたは64ビット）。
• 追加のターゲットのビルド/有効化をカスタマイズするオプション（gdnativeラッパー、モノグルーなし、有効化/無効化：モジュール、ドライバー、非推奨機能など）、組み込みコードを使用して静的にコンパイルするようにライブラリを設定するか、システムライブラリを使用します1つ個別に）。

Mesonはわかりませんが、上記のすべてが提供されている場合は問題ありません（何かを忘れていなければ）。 もちろん、誰かがMesonでビルドシステムを書き直すという耐え難いほどの苦痛を味わってから、ツールとビルド時間がSConsよりもGodotにとって効果的に優れていることを示さなければなりません。

いくつかのサードパーティの依存関係では、Godotを使用してパッチをコンパイルする必要があることに注意してください。 Wrapにはパッチがサポートされていることに気づきましたが、パッチはどこかでダウンロードできる必要があるようです。それでもリポジトリの一部である場合は、管理が簡単だと思います。 また、それらのいくつかは、ビルド全体に適用されるべきではない特別なコンパイルフラグを必要とします。

このような概念実証は非常に価値があると思います。

• 新しいビルドシステムが必要なものすべてを処理するかどうか、そしてそれがどれだけうまく機能するかについて、より良いアイデアが得られます
• 議論するための抽象的なデータではなく具体的​​なデータを提供します

第二の点に関しては、この手段我々はゴドーのビルド速度の違いを見ることができ、我々は我々のビルドスクリプトになるどれだけ簡単に（またはより複雑な）見ることができる、と私たちは、代わりに教育を行うことの選択をするために、より簡単に違いを比較することができますそれが提供できると思うものに基づいて推測します。

-

さて、個人的には、私はこれに賛成でも反対でもないと言わざるを得ませんが、ビルドシステム全体を変更するのではなく（または変更する前に）、追跡する必要のある成果がもっとあると思います。 特にこの重要な時点では、3.0と最初のパッチが可能な限り最良の形になっていることを確認するために、できるだけ多くの手が必要です。 しかし、ビルドシステムを改善したい場合は、CIビルド時間とMonoビルド状況の煩わしさを調べます。 （これらはakienのTODO /

また、バグのある並列ビルドはWindowsで問題が発生しますが、それは個人的には修正された場合に適しています。

TL; DR：

• SConsのドキュメント/リソースが不足していることに同意します。ビルドスクリプトは簡単です。Pythonはそれをいくらか打ち消します。IMO
• 新しい寄稿者として、Godotビルドシステムはセットアップの煩わしさが最も少なく、コンパイルが最初に成功するまでの時間が非常に短いものの1つでした。
• 私はむしろ努力を極力3.0 / 3.1の改善に費やすと、それらが安定しているたら多分これについて考える参照してくださいね
• より良いCIビルド時間とより簡単なMonoビルドがより重要になる可能性があります

私の意見。 :)

記録としては、3.0をリリースし、次のリリース（3.0.1、3.1）に焦点を当てることがこれよりも優先されるべきだと絶対に信じています。
それだけで、他の開発者/特にハイテクに精通したエンドユーザーの利益のために本当にだから、人々は（buildsystemsに仕事は好きではない理由を私は知っている-重要な国連ではありません、それは開発者と貢献者の生活を楽にするために価値があります、しかし最終的にはエンドユーザーの幸福が目標です）そしてこの「機会費用」全体があります。 ビルドシステムの改善に費やされた時間（または、誰に尋ねるかによっては失われた/無駄になった）がプロジェクト自体の改善に費やされる可能性がある場合。 （あなたが私のようで、とにかくC ++側で実際に作業できない場合を除きます。）

そして最終的に、SConsは実際に「正しく機能」します。これは、ほとんどの開発者にとってはおそらく十分であるため、これは最終的には実現することを望んでいますが、3.1または3.2でさえ息を止めていません。それが実際に最初から取り組んでしまうのに十分なサポートを獲得したとしても。

とはいえ、POCの進捗状況を進んでフォローしてくれる人のために、今週後半にフォークでPOCをキックスタートする可能性があります（ビルドシステムの作成経験があまりないので、助けてくれる可能性があります）。しかし、私はおそらくしばらくの間、これに対するプルリクエストを開くことはありません。

私はSConsが遅いとは思っていません、そしてその柔軟性（私たちがたくさん利用している）はおそらく他の何よりも比類のないものです。 SConsも非常に実績があり、ビルドを台無しにすることはありません。

正直なところ、誰かが（概念実証だけでなく）ビルドシステム全体を書き直すことを志願し、それがより単純（コードがはるかに少ない）または

さて、個人的には、私はこれに賛成でも反対でもないと言わざるを得ませんが、ビルドシステム全体を変更するのではなく（または変更する前に）、追跡する必要のある成果がもっとあると思います。

これは、この変更にとって実際には有害ではありません。 つまり、Godotの貢献者のほとんどは、自由な時間に取り組み、彼らが望むことに取り組んでいます。 @NullConstantの場合、「これを行うか、何もしない」（修正したくないと言っているのではなく、実際のC ++コードベースを操作して、なじみのないものをバグハントするのが難しい）のようです。これを行うことは一般的に良いことです。

また、「やるべきことがもっとある」という議論は、IMOを何もしない方法です。 もちろん、それが物事を壊さず、リリースの近くで行われないと確信するまで、何もマージされません。 もっと重要なものがあることに同意しますが、これを開始できないという意味ではありません。

問題は、これに取り組んでいる誰かがおそらくこれを一人でしなければならないということです。 もちろん、コア開発者は特定の質問に答えることができますが、それ以上のことは起こりません。 そのため、SConsは交換されるとは考えられていませんでした。これまで、手を汚したいと思った人はいませんでした。 前にBulletについて言ったように、誰かがBulletを機能させて、それが可能でより良いことを証明する必要があります。そうしないと、現状のままになります。

しかし、SConsは遅いと思います。 それほど遅くはありませんが、進行状況やキャッシュなどによって再構築が遅くなります（ディスクI / Oを使用してキャッシュから読み取ると遅くなります）。そのため、再構築時にそれらを無効にします。 何かを始めるのに少し時間がかかりますが、その後はかなり速くなります。

Mesonが大幅に高速になるかどうかはわかりませんが、誰かが試してみる気があるなら、私はそれに反対しません。

確かに、誰かがそれを行うのに時間がかかり、切り替えを正当化するのに十分なほど大きな改善が見られた場合、私はそれですべてです:)

私が言ったように、私はC ++のバグを探したり、その前に新しい機能を追加したりする準備ができていないので、代わりにこれを行っても大丈夫です。

これにより、私（および/または将来これに取り組んでいる他の人）に、次の目標を達成するためのかなりクリーンな2つの目標が与えられると思います。

• GodotにMesonを使用して任意の形式でコンパイルしてもらいます
• SConsが現在あるのと同じくらい簡単にし、おそらくもっと簡単にします（速度を改善することによって）

そして、SConsの速度はひどいものではないと思います（ビルドプロセスの時間の大部分は実際のリンクとコンパイルによるものなので、ビルドシステムのオーバーヘッドによる速度低下はおそらく無視できる程度です）が、確かに改善される可能性があり、代替手段としてMesonを提供することは、まさにその改善かもしれません。 わかります。

最大の問題は、おそらくシェーダーのようなコードを自動生成するためのpythonビルドスクリプトを置き換えることです。mesonにはそのような機能があるようには見えません。

代わりにMesonを提供することは、まさにその改善かもしれません。 わかります。

それは代替案であってはなりません。明らかに優れている場合はそれに移行するか、提供すらしません。 2つのビルドシステムをサポートしなければならないのはおかしいです。

そうです、それは公平です。

今後数日/数週間でハッキングを開始し、これがどこにでもあるかどうか、そしてそれが本当に追求する価値のある取り組みであるかどうかを確認します（私がその間ずっとそれに取り組んでいる唯一の人であるとしても）。

（ベンチマークのように）見栄えのするものがあれば報告します。

中間子ではありませんが、msvcの下で64ビットのWindows用のbazelの下でgodotを構築するために何が必要かを確認するために、今後数週間でテストを行います。

Bazelは、ビルドの説明が短く、ビルドが高速であるという利点があるもう1つのシステムです。 また、それはグーグルによって維持されているので、どこにも行きません。

とにかく、それを確認することはできませんが、Godotの構築に費やされる計算時間の99％がコンパイラーに費やされている可能性が非常に高いです。 したがって、ビルドソフトウェアのオーバーヘッドがなかったとしても、これによりビルド時間が1％短縮されます。 コードを減らして信頼性を高めることができない限り（または私が間違っていることが証明された場合:)）、5％の減少でさえ価値がありません。

クリーンクローンの生のビルド速度については、大きな違いがあるとは思えません。 ただし、再構築の速度を考慮すると、重要になる可能性があります。 SConsは、新しいコミットをプルしたときに変更されなかった多くのものを常に再構築します（特に、OpenSSLとBulletはどちらも大きなライブラリであり、構築に時間がかかります）。

前に言ったように、SConsの起動は遅いです（実際にコンパイルを開始するまでに数秒かかります）。 無視できるソース全体をビルドしているが、行を変更してテスト用にコンパイルしている場合は、ワークフローを大幅に改善できます（IMOはビルドシステムで最も重要です：コードを操作する人々を支援します） 。 したがって、10分のビルドで5秒が減少することは関係ありませんが、10秒の再構築で5秒が減少することは大きな改善です。

しかし、私は、この点での変更は、それが機能することを証明するために多くのテストを@reduzが述べたように、SConsはビルドを台無しにすることはなく、それは考慮すべきことです。

Bazelは、ビルドの説明が短く、ビルドが高速であるという利点があるもう1つのシステムです。 また、それはグーグルによって維持されているので、どこにも行きません。

「グーグルが廃止したもの」というウィキペディアのカテゴリーも増えています。 :)

@mhilbrunnerいいえ、まだ維持されていますhttps://github.com/bazelbuild/bazel

彼らのポイントは、グーグルがそれを作ったからといって、それが長い間存在するという意味ではないということでした。

ゲーム開発にC＃を採用しているので、 Cakeのようなものを試してみるのもよいでしょう。 自分では試したことがないので、どう思いますか？ 少なくとも1つには、スクリプトはPythonよりも高速に実行されます。

ゲーム開発にC＃を採用しているので、 Cakeのようなものを試してみるのもよいでしょう。

GodotはほとんどC ++プロジェクトであり、C＃のサポートなしでコンパイルできることを考えると、GodotをコンパイルするためにMonoインストールが必要かどうかはわかりません。

MesonまたはCMake（Ninjaジェネレーターを使用）によって提供されるパフォーマンスのレベルは、Godotの目的には十分すぎるはずです。

@Calinouおそらく正しいでしょうが、誰もがC＃の時流に乗っているようですが、個人的にはGodotを使用したゲームスクリプトやXamarin.Formsを使用した生産性アプリに使用しています。また、パフォーマンスを本当に絞りたい場合は、次のようなものを試すことができます。右のC ++へのIL2cppコンバータやジャンプ。 また、Web開発関連のものやシェルスクリプトなど、JavaScript、Python、またはPHPを通常使用するものには、mono / csharpREPLおよびASP.netを使用することも考えています。 問題は、C＃をベースにしたビルドシステムを使用してもかまわないということです。これは、すでにほとんどすべての用途に使用しているためです。 少なくとも私にとっては、「くそー...私が学ぶ必要のある別の言語...なぜ彼らはC ++に固執して-ここにまともな動的/管理された言語を挿入しないのか-」の終わりになるでしょう。

編集：

明確にするために、GodotをビルドするためにMono Frameworkをインストールする必要があることは、私にはそれほど悪いことではありません。いわゆるAAAゲームエンジンははるかに多くのディスクスペースを必要とするからです。

• ゴドー<50メガバイト
• モノサポート（<50メガバイト）+モノラルFrameworkでゴドー（〜350メガバイト）=〜400メガバイト
• Unrealの〜20ギガバイト
• ユニティ〜10ギガバイト
• CryEngine 〜8ギガバイト

さらに、デフォルトでエディターでMonoサポートをハードコーディングし、実行時にC＃スクリプトをサポートするかどうかを検出するロジックをいくつか用意して、Monoフレームワークまたは適切なエクスポートテンプレートを要求することができます。

私はCMakeが大好きで、中間子はかっこいいように見えますが、私はこの記事に同意する傾向があります： http ：

GodotをMesonに移動するためのフットワークに非常に興味があります。 現在、私がGodotに貢献する（そしてそれを使用する）ことを妨げているのはSconsだけです。 私は何年も前にそれを使わなければなりませんでした、そして私は私の人生の中でこれほど苦痛な漸進的な開発経験をしたことがありませんでした。

上にリンクされた記事には、CMakeがすでに存在しているので、それを使用する必要があると主張する、多くのストローマンの議論があります。 Mesonのビルドファイルは非常に読みやすく、Pythonに近い構文を使用しています。 変換は迅速に行うことができます。 私がこのスレッドに投稿しているのは、フットワークが完了した場合、プルリクエストはマージのために考慮されるのでしょうか？

私がこのスレッドに投稿しているのは、フットワークが完了した場合、プルリクエストはマージのために考慮されるのでしょうか？

検討されますが、SConsよりも有利であることが証明されている必要があります。

CMakeをデファクトスタンダードではなく、単なる別のビルドシステムと見なすと、選択肢が多すぎます。 なぜSConsよりも中間子なのか？ または、バゼル/バックもまともなツールですか？ しかし、私がCMakeを支持する最大の議論は、そのエコシステムをサポートするために構築されたツールです。 Clangコンパイルデータベース、複数のオペレーティングシステムへのパッケージ化のサポートなど。私が聞いた唯一の有効な欠点は、構文とドキュメントが悪いことですが、これについての立場を変えるには十分ではありません。

なぜSConsよりも中間子なのか？

Mesonは忍者ファイルを生成します。これはインクリメンタル開発の方がはるかに高速です。 さらに、Windowsでは、VisualStudioのパス操作を行う必要は

または、バゼル/バックもまともなツールですか？

bazelとbuckはどちらもJavaで記述されていることを考えると（依存関係godotは、Androidをターゲットにする場合にのみ存在し、技術的にはNDKpip install mesonを使用して簡単にmeson（およびninja）をインストールできます。

Clangコンパイルデータベース

これは忍者に組み込まれているデフォルトの機能であるため、Mesonはデフォルトでこれをサポートしています

複数のオペレーティングシステムへのパッケージ化のサポート

Mesonもこれをサポートしており、必要に応じてpkg-configに大きく依存しています。

私が聞いた唯一の有効な欠点は、悪い構文とドキュメントです

Mesonは、変数、オブジェクト、および組み込み関数に依存する、非常にPythonに似た構文を持っています。 私の意見では、書く

my_meson_list = ['x', 'y', 'z']
message(my_meson_list)

vs

set(MY_CMAKE_LIST "x;y;z")
message(STATUS ${MY_CMAKE_LIST})

特にcmakeで大文字と小文字が区別される場合とそうでない場合が

# In one file
set(USE_STD_CXX11 "-std=c++11")
set(USE_STDLIB_LIBCXX "-stdlib=libc++")

# Possibly elsewhere
set(LIBCXX $<BOOL:${CAN_USE_STDLIB_LIBCXX}>,$<BOOL:${BUILD_WITH_LIBCXX}>)
set(NO_RTTI $<BOOL:${CAN_USE_NO_RTTI}>,$<BOOL:${DISABLE_RTTI}>)

# Later on...
target_compile_options(my-exe
  PUBLIC
  $<$<BOOL:${CAN_USE_STD_CXX11}>:${USE_STD_CXX11}>
  $<$<AND:${LIBCXX}>:${USE_STDLIB_LIBCXX}>
  $<$<AND:${NO_RTTI}>:${USE_NO_RTTI}>
  # Oh yeah, you're gonna want more of these, because you can't trust compiler interfaces
)

# Generator expressions mean you can't follow the flow of the build to see what is called and defined where. This is a completely valid use of CMake.
check_cxx_compiler_flag(${USE_STDLIB_LIBCXX} CAN_USE_STDLIB_LIBCXX)
check_cxx_compiler_flag(${USE_NO_RTTI} CAN_USE_NO_RTTI)

同等の中間子は次のようになります。

cxx = meson.get_compiler('cpp')
# This is an extremely simplified approach. One can do a different option when dealing with MSVC and gcc support.
args = compiler.get_supported_arguments('-std=c++11', '-stdlib=libc++')
add_project_arguments(args)

ちなみに、そこにあるすべてのC ++ビルドシステムの中で、Mesonは最もひどいものではないことに注意する必要があると思います。 その使用に反対する議論は、ウェブコミックの写真である傾向があり、CMakeが最も使用されている方法について手を振っている人もいるので、それに対処する必要があります。「少なくともCMakeはautotoolsではありません」。

しかし何よりも（そしてこれは本当に重要なことだと思います。特にgdnativeに関してgodotを使用している人にとっては）、Mesonはプリコンパイル済みヘッダーをネイティブにサポートしています。 CMakeはそうではありません（そして、ビルドをハックするためにcotireを使用すると、その価値よりも多くの問題が発生する可能性があります）。

これにより、gdnativeユーザーのビルドがどれだけ高速化されるかはわかりませんが、gccとmsvcが大幅に向上します（少なくとも、msvcのパフォーマンスの向上は避けられません）。 godotにあるごく少量のテンプレートコードにextern templateの使用を追加すると、反復型および増分型ビルドにとって重要な、適切なビルド時間の改善が見られます。

Mesonは忍者ファイルを生成します。これはインクリメンタル開発の方がはるかに高速です。

CMakeは、従来のMakefileの代わりにNinjaビルドファイルを生成することもできることに注意してください。 これは、コマンドラインに-G Ninjaを渡すことによって行われます。 これは、私が試したほとんどのプロジェクトで非常にうまく機能し、全体的にわずかに高速です（さらに、デフォルトですべてのCPUスレッドを使用します）。

Mesonは、私が見た生のパフォーマンス比較でまだ勝っていますが、これは間違いなくMesonとCMakeのパフォーマンスの間のギャップを埋めるのに役立ちます。

はい。ただし、CMakeは自動的に忍者をインストールするわけではなく、デフォルトのジェネレーターではありません。 私の経験では、CMakeの時間のほとんどはプロジェクトの構成に費やされており、最近のバージョンのCMakeではパフォーマンスが大幅に向上していますが、すべての人が最新のCMakeを使用できるわけではありません。

OK、それはかなり徹底的です！ ビルドシステムで大切にしている機能について、よく理解していただけてうれしいです。 プロジェクトが信頼できるC ++の世界にはまだ標準のビルドシステムがあるべきだと思います。 中間子がそれ自体のものではなく、CMakeトランスパイラーであったらいいのにと思います。

プロジェクトが信頼できるC ++の世界にはまだ標準のビルドシステムがあるべきだと思います。

私を信じてください、私以上にこれを望んでいる人は誰もいません。 私は一種のビルドシステムのゴミゴブリンになり、CppConでそれらについて話をしました。 私は残念ながら（または幸運なことに？）システムの構築に大いに関心を持っており、ほとんど執着するところまで来ています。 :)

私はこれを言いたいのですが、WindowsでGodotの長いビルドを行うたびに、Pythonが常にCPUの15％以上を占めていることに気づきました。 開始が遅いだけではないかと思います。

中間子で作られた小さなプロトタイプのgodotエンジンを誰が作るのでしょうか？ 私は、バゼルの小さなテストを作成することはできませんでした。

すべてのオプションを無効にしてテストするには、godotの2dのみのビルドで十分です。

私が最初に直面した障害はcore / make_binders.pyでした。 これは、godotが使用する自動生成されたコードです。

ビルドシステムBazelで最初のプロトタイプを作成しましたが、別の問題でセットアップについて説明します。 https://github.com/godotengine/godot/issues/18518

1週間の時間はありませんが、他の人はBazelBUILDを拡張できます。

笑バゼルはどうやって関わったの？

別のビルドシステムに切り替える機会が一度だけあるかもしれないので、可能な限り最良のオプションを探すべきではありませんか？ 私は、Cake vs Bazel vs Sconsの比較チャートを見ることに興味を持っていましたが、これらのテストのフットワークを行うためにCakeの経験がまったくないことを認めなければなりません。

@rraallvvあなたはケーキまたはCMakeを意味しますか？

@isaachier悪いことに、私はwww.cakebuild.netについて話していました。もっと具体的にすべきだったので、申し訳ありません。

それはC＃だけではありませんか？

@isaachier本当にわかりませんが、SConsがPythonで記述され、C ++をサポートしているのと同じように、Cakeがそれを実行できると思っていました。 それにもかかわらず、私はちょうど彼らのギッターチャットで尋ねました、私はここに答えを再投稿します。

記録のための@rraallvv主要なビルドシステムを並べて比較するというアイデアは素晴らしいアイデアだと思います。 ：ここで私は私が（ビルドシステムの開発者によって書かれていない）かなり公平だと思うことを、オンラインで見つけたものであるhttps://carlosvin.github.io/posts/choosing-modern-cpp-stack 、 HTTPS：//www.reddit。 com / r / cpp / comments / 6euc7b / build_systems_bazel_buck / die6g1y /、https：//stackoverflow.com/a/12022652/1930331 。

私の個人的な意見：

• CMake ：かなり醜い言語ですが、どこにでもあり、事実上業界標準です。
• SCons ：低速、古い、IDKステータス。 Pythonを使用します。
• meson ：信じられないほど遅くない、新しくてかっこいいPythonベースのビルドシステム。 主な欠点は弾道で​​す。 これが今週のビルドシステムの別のフレーバーになるかどうかは不明です。
• Autotools ：古く、ツールのサポートはありません（つまり、Clangオートコンプリートサポートまたは静的分析用のコンパイルデータベース）。 Windowsはサポートされていません。 絶対に避けてください。
• bazel ：Googleのパッケージマネージャー/ビルドシステムが1つにまとめられました。 Hunterなどのプラグインを使用してCMakeに多くを追加することはありません。 また、グーグルのソフトウェアは、一般大衆ではなく、グーグルが必要とするものに焦点を合わせる傾向があります。 長期的な軌道を測定するには新しすぎます。

C ++のデファクトスタンダードが必要で、CMakeは現在最大の「市場シェア」を持っているため、機会があればいつでもCMakeをプッシュしようとしています。

@isaachierその情報を共有してくれてありがとう、C ++でスクリプトをサポートするビルドシステムがないのでC＃をプッシュしています、それはばかげているように聞こえるかもしれませんが、なぜ誰かがまだそれをしていないのかわかりません、例えばこのC ++ REPLは、次のレベルに進み、どちらが優れているか、より速いかなどの議論を終わらせたい場合に、ビルドシステムに使用できます。

わかりません。 C ++は恐らくひどいビルド言語でしょう。 速度低下は、使用されるスクリプト言語の詳細ではなく、内部ビルドシステムのコアAFAIKと関係があります。

@isaachier SConsはPythonで記述されているため非常に遅いと思いますが、誰かがビルドシステム全体をC ++に移植し、JITでC ++スクリプトをコンパイルしてそれらのビルドを実行するようにすると、かなりの時間がかかります。もっと早く。 たぶん、そこにあるすべてのビルドシステムに同じことが当てはまる可能性があります。

これは素晴らしいアイデアですが、mesonはほとんどのアカウントで遅いとは見なされていませんが、Pythonで記述されています。

GNOMEプロジェクトは現在、中間子を支持してautotoolsを放棄しているため、中間子が今週のフレーバーになるとは思えません。

さらに、Sconsは、Pythonで記述されているためではなく、ビルドも実行するために低速です。 これはmakeやninjaのような直接ビルドシステムですが、定義に大量のXMLを使用し、そのコードの大部分は実際にはXSLT変換にすぎません。

一方、Mesonは、ビルドスクリプトを実行して依存関係ツリーを生成し、これをninjaファイルにダンプします。 忍者が速いので、中間子は速いです。 さらに、CMakeのように、Mesonではすべてが文字列であるとは限りません。

最後に、C ++でスクリプトを作成できる開発ビルドシステムがいくつかあります（実際にはそのうちの1つを書いています）。ただし、まだ存在しないビルドシステムに移行するようにgodotに依頼します（さらに悪いことに、私自身が書いていること）は少し傲慢であり、私のそれほど謙虚な意見ではありません;）

繰り返しになりますが、現在の開発ワークフローではPythonが必要です。 だから、中間子もそうです。 そしてそれは、Pythonのpipツールを呼び出すのと同じくらい簡単にmesonに移行することを可能にします。

私は@reduzに完全に同意しますが、SConsも実際には遅いとは思いません。

@ slurps-mad-ripsが言ったように：

Sconsは、Pythonで記述されているためではなく、ビルドも実行するために低速です。

男のスコン：

sconsは、生成される可能性のある同時タスクの数を引数として取る-jオプションを介して、複数のターゲットを並行して構築することをサポートします。
scons -j 4

私は8c16tのCPUを持っているので、「scons p = x11-j18」を使用すると非常に高速です。
デフォルト設定の「-j1」として「sconsp = x11」を使用するよりも10倍高速です。
2018年に誰かがシングルコアCPUを持っていますか？
CPUを完全に機能させます。
ぜひお試しください。

誰もがこれらの大きなCPUを持っているわけではありませんが、さらに重要なことに、中間子（まあ、忍者）は増分再コンパイルではるかに高速です。 Sconsは、デフォルトで、MD5ハッシュサムを実行して、ファイルが変更されたかどうかを確認します。 GodotはMD5タイムスタンプ設定を使用します。これは、タイムスタンプが変更された場合にのみファイルをハッシュすることを意味します。 それはまだばかげています。

何が良いかを証明する最良の方法は、新しいものを書いて参照することだと思います:)

Sconsは多くの人にとって高速ではありません。特に、-j1を超える問題が発生したWindowsユーザーはそうです。

@ slurps-mad-ripsプロジェクトによって異なります。 忍者はそのスピードを少し誇張しすぎているようです。 この記事を参照してください： http ：

@isaachierのベンチマークは、忍者とスコンではなく、メーカーと忍者の間にあるので、私がそれに注意を払いたくない場合は、私を許さなければなりません。 ;）

何が良いかを証明する最良の方法は、新しいものを書いて見ることだと思います:)

私は同意します、自転車の脱落には意味がありません。 より良いビルドシステムについて意見がある場合は、それを実装して、より良いことを証明してください。 そうでなければ、これは意見の議論であり、どこにもつながりません。 @fireはすでにます： //github.com/godotengine/godot/issues/18518。

@ slurps-mad-SConsではなく、まったく異なるトピックをリッピングします。 私はただ作る対忍者が狂った違いではないことを意味しました。

ちょっとした更新：私は中間子に移動しようとするのをあきらめています。 それは断片的であり、ビルドファイルは少し読みやすくなっていますが、現在のシステムを最新の状態に保つことは、sconsを中間子に移動する代わりに、私の（現在はまれで不足している）自由時間のほとんどが費やされる場所です。

現在、多くのコードと操作がsconsスクリプトに直接配置されているため、別のビルドシステムへの移行がより困難になっています。 どちらかといえば、sconsからコードを生成する既存のPythonスクリプトを切り離すのに時間を費やす必要があります。これにより、meson、cmake、さらにはbazelなどの別のビルドシステムへの移行が非常に簡単になります。

すべてのコード生成を移動するためにパッチがマージされたのは良いことです。 https://github.com/godotengine/godot/pull/17595あきらめないでください！

SConsプロジェクトの共同マネージャーはこちら。 いくつかのメモ：
1-SConsは活発に開発されており、Githubへの移行以降、プルリクエストの割合が増加しています。
2-ヌルインクリメンタルビルド時間の約50％を担当し、それに対処するために積極的に取り組んでいるSConsのいくつかの特定の部分を特定しました。 （Subst機能）
3-SCons3.0でPython3.5 +（および2.7.x）のサポートを開始しました
4-N個の異なるビルドシステムへの移植を試みる代わりに、SConsの改善に役立つ時間を提供する方が、開発者の時間をより効果的に使用できる可能性があることを提案します。
5-私たちは、3.0.0および3.0.1でリリースされたパフォーマンスの向上において、ぶら下がっている果物のいくつかをプロファイリングすることによって特定し、対処しました。 以前のバージョンを使用している場合、ヌルインクリメンタルビルドは5〜15％遅くなる可能性があります。 （Python 2.7.xを想定）

いつものように、SConsプロジェクトは準備ができており、遭遇した問題でSConsを使用するプロジェクトを支援する用意があります。

SConsとgodotのいくつかの「統計」。

私は、2008年頃の4コアCPUであるQ6600を使用しました（そして今でも使用しています）。これは、現在「すべて」使用しているプロセッサ（i7s）よりも2.4GHZ（およびサイクルカウントあたりの命令数が少ない）です。

Q6600では、ビルドに3〜5分（またはそれ以上ですが、正確な数はそれほど重要ではありません）かかりました。そのうち、依存関係などのツリーを解析するSConsによって約35〜40秒が費やされました（準備作業）...したがって、cl.exe（MSVCコンパイラ）プロセスの実行に費やされる時間の80％が何度も繰り返されます。

したがって、パフォーマンスと最適化に関しては、SCons（実際には、SConsではなくPython）に、必要以上に時間がかかるひどいプロセス呼び出しシステムがあるか、他のツールがプロセスごとに1つのファイルをコンパイルしていない（SConsが現在そうであるように）場合を除きます。 1ファイルあたりのプロセスのオーバーヘッドは重要です（私はcl.exeコンパイルの内部と起動のオーバーヘッドの専門家ではありません）、より高速なビルドシステムが生成する唯一のパフォーマンスの最適化は、おそらく依存関係ツリーフェーズの構築と複雑化のための他の準備作業です。

そのため、5分のビルドから35〜40秒を最適化しています（i7では、おそらく3分のマルチコアビルドから20秒のシングルコアセットアップステップを最適化しています）。

要約すると、私が正しく覚えていれば、3〜5分は実際には4コアのマルチコアビルドですが、シングルコアビルドには約10分かかりますか？ テストを再実行する必要があります...

したがって、SConsを「最適化」するということは、ビルド開始の最初の35秒を多かれ少なかれ最適化することを意味します...

SConsと他のより高速なビルドシステムに関しては、「最適化」に関する限りです...すべてのobjファイルに対して単一のcl.exeを呼び出さないようにすることで、実際のコンパイルを少し最適化できる可能性がありますが、それはその場合のみです。プロセスのオーバーヘッドは重要です（HDDが常に（CPUではなく）実際のIOボトルネックになるのではないかと心配しています。これは、SSDなしでは回避/軽減できません）

上記のすべての段落は、「フルビルド」を考慮しています。 とは言うものの、SConsはすべてがすでにビルドされている場合は「チート」し、手間のかかる整合性チェックに合格するため、単一のファイルを変更すると、実際には「単一のファイル」がコンパイルされてからすべてがリンクされ、「フルビルド」がある程度になります。インクリメンタルビルドの）。 ただし、これには35〜40秒の完全な依存関係ツリーの事前計算が必要です...

つまり、「インクリメンタルビルド」は私の古いコンピューターでは約45秒で、2年前の初心者のときにCPUバウンドになると思っていましたが、実際にはIOバウンドである可能性があります（hddで数千のファイルをチェックします） ）完全な依存関係のスイープ/ツリーの再構築の場合...したがって、IOバウンドの場合、「より高速なbuidlsystem」はそれを解決しません...

2年前の私のハックなアイデアは、ファイルシステムの「ウォッチャー」をSConsにアタッチし、SConsに単一の変更されたファイルを実行して再コンパイルさせ（依存関係は自動的に）、すべてを再度リンクさせることでした...私は今日、リンクがおそらく完全な依存関係スイープを実行することを認識しています...とはいえ、依存関係ツリーのスイープ/再構築はオプションで強制終了でき、SConsはキャッシュされたdepツリーを使用します...約15〜20を節約します35秒の事前計算ステップの秒数（最初の15秒は避けられないようです）が、SConsのように常に「完璧な」ビルドを保証するわけではないかもしれません（ただし、開発の増分ビルドでは重要ではないかもしれません...速度が価値のあるトレードオフ）。

私は今、npmやnpm watch ...や、現在慣れていない他のシステムを介してハッキングできる十分な知識を持っています...しかし、それは後で、時間があるとき（現在はありません）です。

これは少し長くなっているので、ここで終了しますが、これらの段落のポイントは、私自身が好きだったように、誰かを落胆させるのではなく、「統計」情報を提供することでした（ビルドシステムでの作業が好きな場合は先に進んでください）。 GodotのSConsのいくつかのものを修正します。 ここで皆さんに役立つ情報があればいいのですが。

統計を複製/やり直したい場合は、統計情報（タイマー関連）をオンにするまでSConsドキュメントを参照するか、依存関係の再解決（「事前計算」の最初の20〜30〜35秒）をオフにする方法を見つけてください。 ）..。

または、手動による解決策が少し少ない場合は、タイマーのデバッグ情報がすでに存在している必要があります（編集：おそらくそうではありません。誰かがvsプロジェクト生成の甘い更新のように見えますが、この段落は古い情報である可能性があります）。 SCons（SConstructファイルの最後）... VSプロジェクトの生成方法に関する情報は、godotWebサイトの「Windowsコンパイルチュートリアル」にあります。 その後、VSからSConsを実行できます。Godot3でテストしていませんが、生成されたプロジェクトはおそらく機能するはずです...これはオプションですが、> log.txtにsconsを追加することも別のオプションです（など）。 ..。。

誰かがこの情報がお役に立てば幸いです。

@Griefchief少し明確にするために、

実際、「nullインクリメンタルビルド」（実際には何も再ビルドする必要はありませんが、それを確実にするために、sconsは依存関係ツリー全体を処理する必要があります）が私たちが取り組んでいるケースです。

一部のプロファイリングでは、コマンドラインの処理における非効率性（ターゲットが変更されていないことを確認するためにすべてのターゲットに対して実行する必要がある）が特定されていることが指摘されています。 その大部分はSubst（）ロジックです。 これはいくつかのトリッキーなコードであり、これまでのところ、より単純で安全な方法で実装されていますが、効率的にひどい方法ではありません。

もう1つのホットスポットは、sconsignファイルの読み取りと書き込みです。現在、cpickleで実装されており、常に全体として読み取りと書き込みが行われます。 スピードアップおよび/またはよりインクリメンタルにする方法についていくつかのアイデアがあります。 とにかく、改善のために将来のリリースを見てください。

ちなみに、MSVC_BATCHを試して、Windowsのビルドが高速化されるかどうかを確認してください。

MSVC_BATCH
true値に設定すると、Microsoft Visual C / C ++コンパイラを呼び出すときにSConsがオブジェクトファイルのバッチコンパイルを行う必要があることを指定します。 同じ出力ディレクトリにターゲットファイルを生成し、同じ構築環境を使用してSConsで構成された、同じソースディレクトリからのソースファイルのすべてのコンパイルは、コンパイラへの1回の呼び出しで構築されます。 オブジェクトファイルがビルドされてから変更されたソースファイルのみが、（$ CHANGED_SOURCES構築変数を介して）各コンパイラ呼び出しに渡されます。 オブジェクト（ターゲット）ファイルのベース名（.objを除く）がソースファイルのベース名と一致しないコンパイルは、個別にコンパイルされます。

@ bojidar-bgはい、はい、実際にはインクリメンタルビルドについても話していました。ヒントをありがとうございます：D

@bdbaddogこんにちはbaddog、あなたの情報のために、私はあなたのコメントを見る前に実際に私のこの大きなコメントを書いたので、それは実際にはあなたのコメントの何も具体的に言及していません...しかしあなたはなんとかいくつかの「懸念」私は（本当に他の人のための情報を）私たちが同時にコメントを書いている間に持っていました...

そして、私はあなたの時間を「無駄に」したくなかったので、あなたにpingしたくありませんでした：D、しかし、将来、godotビルド/ sconsにもう少し時間を費やすなら、私はそうするつもりです（私はそうするつもりです、私はとても忙しいです））

ここに入力していただきありがとうございます！

@bdbaddog BD、あなたがサポートを提供しているので、私がここで尋ねるかもしれません：

npm watchをファイルシステム（godotのソース）に接続し、どの正確なファイルが変更されたかを知っている場合、SConsで何かメリットがありますか？

これで、npm watchを介してsconsを実行し、ファイルをそれにプッシュできます...

scons [godotオプション] / file / that / was / changed。

これは明らかにそのファイルを再コンパイルし、おそらくGodotのdepツリー全体を回避しますか？ 正しい？ したがって、depツリートラバーサルには20秒もかかりませんが、確率は1未満ですが、更新された.objファイルが1つ取得されます（変更内容によって異なります）。 その1つのファイルのgodotdepツリー全体を実際に通過することはありませんか？ この例では、depツリーの走査が少ないという利点があります（そして、通過するファイルが全体的に少なくなるなど、depツリーキャッシュを再利用しても得られない他の利点がありますか？）？

さて、もし私に利点があり、すべてをもう一度リンクしたいのであれば、「単純な」リンクフェーズのために完全なツリートラバーサルが必要でしょうか？

このユースケースは現在Sconsでサポートされていない可能性があることを理解しています（すべてを再度リンクするだけです）が、実用的および理論的な観点から質問していますか？ キャッシュされたdepツリーは「doptreeを実行しない」オプションで再利用でき（忘れてしまいました。2年経ちました）、それは一部のユースケースで機能し、そのユースケースは新しいファイルが追加されていないことを理解しています。 ？ （npm watchは新しいファイルの追加を警告し、それを検出した場合は完全なdepツリーの更新を行うことができます...つまり、「depツリーの一貫性の確保」をnpm watchのようなファイルウォッチャーにプッシュして、自動化します。 npm watchなどのプログラムに対してユーザーが手動で行う「依存関係キャッシュを使用する」オプションを入力します...プログラムにユーザーではなく一貫性を心配させ、ユーザーが保存した瞬間に「リアルタイム」でそれを行います。ファイル、sconsがそれを行うためのより多くの時間を与えます）

私の考えの中に、（実用的かつ理論的に）最適化として機能しないものがありますか？他の提案がありますか（npm watchのようなものが物事を処理できる場合、完璧なビルドを保証する必要はありません、それも問題ありません） ）？ アドバイスしてもらえますか？ ありがとうございました！

要約すると、ユースケースは次のようになります。

1）godotのソースディレクトリでnpmwatchのようなファイルウォッチャーを実行します
2）ユーザーが古いファイルを保存/変更する
3）sconsは、npmによってそのファイルに対してすぐに実行されます。
4）コンパイルが成功した場合、npmはsconsにリンカーを実行して実行可能ファイルをリンクするように指示します。

4.1）depツリーがキャッシュされている場合（フルビルドがすでに実行されている場合）、npmは、この時点でキャッシュされたバージョンのdepツリーとリンクするようにリンカーに指示できます。
4.1）キャッシュされたdepツリーが検出されない場合、npmwatchは完全なgodotビルドを実行します
4.2）新しいファイルの追加など、キャッシュの無効化が検出された場合は、完全なdepツリートラバーサルを実行します（npmはsconsで「usecached deptree」オプションを使用しません）。

これで私のアイデアが少し理解しやすくなることを願っています。この時点で何が問題なのか教えてください; D

PSこれは35のnullインクリメンタルビルドを15秒短縮するコマンドであり、「明らかな」結果になると思います...基本的にここで説明する内容を自動化したいです（多かれ少なかれ、+どの正確なファイルをsconsに知らせます）それが何らかの形でそれを助ける（またはそれがそれを助けることができる）場合は修正されました）：

https://www.scons.org/doc/latest/HTML/scons-user/ch06s04.html

だからここにいくつかのことがあります（順不同ですが、 yoloのために数字を使用しています

1）インクリメンタルヌルビルドは、基本的に忍者ファイルを生成するツールでは何もありません。 Chromeには、AFAIK、2秒未満のヌルインクリメンタルビルドがあります。 これは重要な注意事項です。 npm watch下での35秒の15への低下は、中間子またはcmakeベースのNinjaビルドと比較してまだ非常に大きいためです。 Ninjaは、コマンドラインが変更された場合に再構築を実行するという点でSconsと同じことを実行します（もちろん、makeはこれを実行しません）。

2）CMakeは最近、globシステムへの引数としてCONFIGURE_DEPENDSを使用する機能を実装しました。 xcodebuildやmsbuildなどのツールはこれまで（そして現在）ディレクトリ変更の検出をサポートしていないため、これは常に推奨されていません。 これは、Sconsが改善できることの1つですが、これを実装するためにプロジェクトを深く掘り下げる時間も忍耐力もありません。 基本的に、すべてのOSは、追加ファイル、変更ファイル、削除ファイルなど、内容が変更されるとディレクトリを更新します。 増分変更を行う場合、変更されたディレクトリを簡単にチェックし、再構成チェックでそれらのディレクトリのみをグロブすることができます。 これにより、ツリー全体をグロブするのではなく、ビットを小さくするために行われる作業を減らすことができます。 小さなプロジェクトの場合、これは問題ありません。 これがgodotに役立つかどうかは、いくつかのテストが必要であり、それが役立つかどうかを確認するのは大変な作業です。

3）Sconsがより注目を集めているのを見るのは良いことですが、個人的には、godotがより使用されているビルドシステムに移行する方がコミュニティ全体にとって良いと思います。 Sconsを使用する大規模なプロジェクトのgodotの外では考えられません。 GNOME / GTKは最近mesonに移動し（CMakeをスキップ）、KDEはかなり長い間CMakeを使用しています。 これは事例証拠（したがって基本的な確証バイアス）ですが、godotを試したいが、二度とスコンに触れる必要がないC ++開発者を何人か知っています。 開発者の口に残っている厄介な経験、したがって酸っぱい味を取り除くことは困難であり、私は正直に言って、Sconsプロジェクトが最高であることを願っています。 しかし、C ++コミュニティ全体がすでに長いコンパイル時間を嫌っていることを私は知っています。 長いインクリメンタルヌルビルド（または1ファイルの長いインクリメンタルビルド）は、現代の世界では悪夢です。

もう一度やり直すつもりですが、CMakeをターゲットにするかもしれません。 多くの作業を実行できる変換スクリプトを持っているmesonのおかげで、CMakeからmesonへの移行は非常に簡単です。 CMakeは、新しいFetchContentモジュールを使用して、依存関係の処理を少し簡単にする可能性があります。 それがどのように機能するかを見ていきます。 これらのcodegenスクリプトが別々のファイルに移動されてよかったと思います。 別のC ++標準への移行がtarget_compile_features(<target> (PUBLIC|PRIVATE|INTERFACE) cxx_std_<number>)と同じくらい簡単であるという理由だけで、CMakeの使用は素晴らしいでしょう

明らかに、ビルドシステムに関連するものはすべて論争になるでしょうが、試みても害はありません。

正直に言うと、（そしてこれは無茶なことになるかもしれませんが）私はそれを改善するためにSconsプロジェクトを深く掘り下げたいとは思っていません。 おそらく2020年以降、Python 2.7が正式に完全に廃止され、プロジェクトをPython 3.5以降に進めることができるのは、おそらく非同期操作を使用して、調査または改善する価値があるだけです。 それまでは、触る必要はありません。

おそらく2020年以降、Python 2.7が正式に最終的に完全に廃止され、プロジェクトはPython 3.5以降に進むことができますが、調査または改善する価値があるだけです。

Scons3はPython3.5以降をサポートしています：

どうすればSconsをそれほど嫌いになり、CMakeのような構成の混乱が好きになるのか、私にはよくわかりません。ユーザーの場合、独自のビルド設定を定義するのはさらに難しく、オプションとそのタイプ、および何が何であるかを理解するのは困難です。は内部定義であり、それは私に苦痛をもたらしただけであり、Godotがそれを使用しなかったことに実際に安心しました。

いずれにせよ、それがより良い解決策になると思われる場合は、続けて試してみてください。CMakeに対する私の見方を変えることになるかもしれません。

ユーザーの場合、独自のビルド設定を定義するのが難しい場合は、

それが尋ねられた場合、CMakeは間違って使用されています。 すべてのツールチェーン設定はツールチェーンファイルに含まれている必要があり、プロジェクト固有の構成はフラグを介して渡されます（または、GUIまたはキャッシュファイルの編集など）。 すべてが文書化されて入力されます。プロジェクトの作成者でさえ、公開された構成を文書化して入力することができます。 CGoldと最新のCMake標準を読む必要があります。

@Faless誰もCMake言語がひどいことを否定しません。 しかし、実装はクラス最高です。 この問題を軽減するために、より良い言語からトランスパイラーを作成する可能性を検討してきました。

@ OvermindDL1は、CGoldを読むという提案が大好きです。

それが尋ねられた場合、CMakeは間違って使用されています

さて、私が遭遇したすべてのプログラムは、それを間違って行っていたと思います。

正直なところ、 -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=onを介してフラグを変更する必要はありません（本当に？ on ？）。 キャッシュファイルO_oを編集するというアイデアは言うまでもありません。 または、フラグを変更したい場合は、基本的にビルドフォルダーを削除して最初からやり直す必要があります（キャッシュが異なるためです！）...インクリメンタルビルドの場合はこれだけです...

編集：また、Sconsについて私が本当に気に入った点の1つは（少なくともGodotでは、これはもちろん他のビルドシステムでも可能かもしれません）、実際には標準やドキュメントを読んでおらず、 scons -h実行するだけです。 Godotフォルダー内の

GitHubで見たビルドファイルの95％が間違っています。 人々はシステムの構築に怠惰になり、カーゴカルトの慣習に従って何かをまとめます。

@isaachier 、ちょうどメトリックとして、悪いと良いCMakeファイルの2つの例を提供できますか？ これをどのように考えますか： //github.com/ARMmbed/mbedtls/blob/development/CMakeLists.txt ？

私が見たほとんどよりも優れています。 それでも、CMake> = 3.0を使用していない場合は、最新のCMakeを使用した経験はありません。

さて、私が遭遇したすべてのプログラムは、それを間違って行っていたと思います。

私はそれが最近うまくいくのを見る傾向があります。

正直なところ、-DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG = on（本当に？on？）を介してフラグを変更する必要はありません。 キャッシュファイルO_oを編集するというアイデアは言うまでもありません。 または、フラグを変更したい場合は、基本的にビルドフォルダーを削除して最初からやり直す必要があります（キャッシュが異なるためです！）...インクリメンタルビルドの場合はこれだけです...

onを使用する必要はなく、 true 、 1 、およびその他のさまざまなものを使用できます。 フラグ名とよく合う適切なブール名を選択できるようにするためです。

また、オプションを変更した場合でも、ビルドフォルダーを再構築する必要はありません。cmakeは、必要に応じて再構築するのに非常に優れています。

それでも、C / C ++ビルドシステムに触れるすべての人は、 CGoldとCMakeの公式マニュアルを読む必要があります。 それは多くの場合だけでなく、大量の短い、CMakeの権利を使用するのはとても簡単です。 古代のCMake2方法論は使用されるべきではありません。 しかし、実際には、CMake 2.xバージョンに依存している人は、絶対に間違ったことをしています（ターゲットとツールチェーンを適切に使用していない、オプションを適切に設定していないなど...）。

説明をありがとう、私は懐疑的なままですが、それがGodotのためにどのように機能するかを見るのを楽しみにしています:)。

@ slurps-mad-rips C ++ 11モードを有効にするための想定されるCMakeサンプルコードを含む投稿は、次のようなさまざまな理由で完全に非標準のCMakeです。

• 公開されていない変数の設定。
• ツールチェーン以外のファイルに設定されたツールチェーン引数。
• C ++ 11モードを有効にするような方法では絶対にありません。
• 非効率的な。

次の投稿に示されている、簡略化されたものとして自己記述された中間子コードを考えると、

cxx = meson.get_compiler('cpp')
# This is an extremely simplified approach. One can do a different option when dealing with MSVC and gcc support.
args = compiler.get_supported_arguments('-std=c++11', '-stdlib=libc++')
add_project_arguments(args)

簡略化された同等のもの（さらにプロパティを追加できるという点で）CMakeは次のようになります。

set_target_properties(godot PROPERTIES CXX_STANDARD 11)

これにより、使用するツールチェーンがそのモードを設定する必要があることを確実に認識できます（また、それをサポートしていないコンパイラを使用している場合は、障害の処理方法を指定できます）。 ビルドファイル内の特別なコンパイラ固有のコマンドラインフラグはツールチェーンファイルにのみ存在するはずであり、前の投稿に示されているメソンの例が実際に特定の引数を指定しているという事実は、サポートされているコンパイラをハードコーディングしていることを意味するため、非常に貧弱な形式であると想定します。

考えられるほぼすべてのツールチェーン（さまざまな種類のMSVC、GCC / Clang、android、iOS、emscriptenなどのすべての標準を含む）用のビルド済みのCMakeツールチェーン

編集：そして、広範なサポートを決して軽視しないでください。 mesonがKDevelop用のプロジェクトファイルを生成できることについては何も見つかりません（私が使用しているIDEは、ビルド形式としてCMakeを使用しています。仕事でCLionを使用することもありますが、CMakeも使用しています）。 Visual Studio！）でも、CMakeプロジェクトをネイティブに開くことができるようになりました（必要に応じて、CMakeがほとんどのIDEのプロジェクトを直接生成できることに加えて）。

@ OvermindDL1

ほんの少しでも非標準のCMakeではありません。 コードサンプルは、 CXX_STANDARDが存在しないバージョンであるCMake3.0を対象としています。 ここから、 target_compile_featuresとcxx_std_および標準の番号を使用していることが簡単にわかります。 これは、標準バージョンを設定するための新しくてモダンなcmakeの方法です。 set_target_propertiesは、古いターゲットごとのアプローチです。
実際、 CMakeのドキュメントから取得した正確なコードは次の

target_compile_features(mylib PUBLIC cxx_std_11)

ただし、 CXX_STANDARDは、設定されてしません（ほとんどのLinuxディストリビューションでデフォルトでlibc ++を使用するように設定されることはありません。これにより、リンカーエラーとABIの問題が発生します） 。 現時点でこれを行う唯一の方法は、コンパイラが-stdlib=libc++をサポートしているかどうかを確認し、ジェネレータ式を介してコンパイラに渡すことです。 これに関して、公開されていない変数に関係するものは何もありません。

さらに、特に次の試みでCMake over Mesonをターゲットにすることを考えると、数か月前に行ったコメントから修正するためにコメントを削除していただきありがとうございます。 それはタクトに欠けており、私の意見では会話に何も追加しません。

CMake 3.0は十分に古く、サポートされなくなりました（2014年6月10日）。 現時点ではCMake3.12を最新の状態に保つことをお勧めしますが、現在CMake3.10未満のものを実行している必要はありません。

そして、はい、あなたが与えた例は完全に反対することをお勧めします（CGoldでさえそれをしないと述べていると思います）。

そして、はい、私はtarget_compile_featuresを意味しました。 ^。^;

ただし、CXX_STANDARDはclangのlibc ++サポートを設定しません。これは、clangがLinuxでデフォルトでlibstdc ++を使用するため、構成されていない場合です（また、ほとんどのLinuxディストリビューションでデフォルトでlibc ++を使用するように構成されていないため、リンカーエラーやABIの問題が発生します）。 現時点でこれを行う唯一の方法は、コンパイラが-stdlib = libc ++をサポートしているかどうかを確認し、ジェネレータ式を介してコンパイラに渡すことです。 これに関して、公開されていない変数に関係するものは何もありません。

現在のツールチェーンはすべて、少なくともC ++ 14を使用してコンパイルするので、clangに対しては問題なく実行します（およびいくつかのC ++ 17）。

さらに、特に次の試みでCMake over Mesonをターゲットにすることを考えると、数か月前に行ったコメントから修正するためにコメントを削除していただきありがとうございます。 それはタクトに欠けており、私の意見では会話に何も追加しません。

申し訳ありませんが、バックログを読んでいたので日付に気づきませんでした（そしてここにはたくさんのバックログがあります）。 私は、数年前に見たものから、あらゆる種類の現代的な提案に対してひどく間違っているように見え、その直後に投稿に修正が見られなかったため、誤った情報が広まらないようにしたいと思ったのに気づきました。 :-)

現時点でこれを行う唯一の方法は、コンパイラが-stdlib = libc ++をサポートしているかどうかを確認し、ジェネレータ式を介してコンパイラに渡すことです。

しかし、はい、それは絶対にこれまでに、これまで、ビルドファイルには表示されませんツールチェーンファイルの仕事、です。

これに関して、公開されていない変数に関係するものは何もありません。

設定され、単一の場所でのみ他の場所で使用される変数を参照していました。これは、さまざまな理由から、とりわけCGoldでは推奨されていません。

CMake 3.0は十分に古く、サポートされなくなりました（2014年6月10日）。 現時点ではCMake3.12を最新の状態に保つことをお勧めしますが、現在CMake3.10未満のものを実行している必要はありません。

彼らはすべきではありませんが、それでもいくつかの場所はそうです。 最新のテクノロジーを使用して最新の状態を維持しようとするゲームエンジンの場合、最新のCMakeを使用することは問題ありません。 しかし、私は3.5や場合によっては3.4などの古いバージョンで立ち往生している非常にアクティブなプロジェクトをよく知っています。 実際、いくつかのよく知られているCライブラリはまだCMake 2.8をターゲットにしています（SDL2、libssh2、libgit2などを参照）。確かにそれはお尻の大きな痛みです。

ただし、そうです、それはツールチェーンファイルの仕事であり、ビルドファイルに絶対に表示されるべきではありません。

この仮定（ツールチェーンファイルは適切に記述されており、すべての可能なシステムとすべてのバージョンのCMakeをカバーしている）を行うことは、現在の一般的なC ++エコシステムで問題を引き起こしています。 clangを使用する場合、libstdc ++またはlibc ++用にコンパイルするオプション（特にFetchContent呼び出しを介して使用する場合）は、ライブラリーによって提供される必要があります。 CheckIncludeCXXとCheckCXXCompileFlagは、GCCには存在しないが、Clangには存在する（またはその逆の）一部のフラグにも必要です。 ここでの主な問題は、コンパイラインターフェイスが大幅に分岐し、ベンダーが互換性オプションを容易にするために時間を費やしたり、共通のインターフェイスについて議論したりする代わりに、その動作が私たち、つまり開発者がコードを書くことだけであるときに押し付けられることです。 私を信じてください。この地球上の誰も、CとC ++のビルドシステムと依存関係の管理の状態に私ほど腹を立てていませんが、CMakeの既存のライブラリの実用主義が必要です。 ビルドシステムからCMakeに移行することの良い点は、最新かつ最高の機能でゲートを開始できることです。 誰もそれに触れたくないので、問題はビルドシステムの停滞になります（コード生成ビルドスクリプトを別々のスクリプトに蹴った勇敢な魂を除いて）が、手に負えないようにするためにいくつかの作業が必要になります（それはそうなるでしょう...私はそれがビルドシステムであることを意味します。彼らはいつもそうします）

私は、特にCMakeでビルドスクリプトを書くことを実際に楽しんでいる一人の男でなければなりません;）。

この仮定（ツールチェーンファイルは適切に記述されており、すべての可能なシステムとすべてのバージョンのCMakeをカバーしている）を行うことは、現在の一般的なC ++エコシステムで問題を引き起こしています。 clangを使用する場合、libstdc ++またはlibc ++用にコンパイルするオプション（特にFetchContent呼び出しを介して使用する場合）をライブラリーで提供する必要があります。

このようなものは、ツールチェーンが操作できるツールチェーンに渡されるプロパティである必要があります。

非常にユニークなセットアップがある場合と同様に、たとえば非常にカスタムなandroidビルドなどのツールチェーンファイルを含めることは完全に合理的です（ただし、cmakeツールチェーンの拡張されたポリーセットは、これまでに必要なほとんどすべてをカバーしています）。

誰もそれに触れたくないので、問題はビルドシステムの停滞になります（コード生成ビルドスクリプトを別々のスクリプトに蹴った勇敢な魂を除いて）が、手に負えないようにするためにいくつかの作業が必要になります（それはそうなるでしょう...私はそれがビルドシステムであることを意味します。彼らはいつもそうします）

これは実際にCMakeを選択するための素晴らしいポイントです。これは、10年以上の過去の経験（良い面と悪い面の両方）を扱った後、今では非常にうまく機能する、明確に定義された一連の標準を備えています。

私は、特にCMakeでビルドスクリプトを書くことを実際に楽しんでいる一人の男でなければなりません;）。

私は確かに他の選択肢と比較してそれを楽しんでいますが、それは私にとって意味があるほど長く書いていますが、それは間違いなくすべての人にとってそうなるという意味ではありません。 ^。^;

私は何年にもわたって多くの異なるビルドシステムを使用してきました。 最近私にとって最も理にかなっているのはCMakeですが、SConsの魅力とその柔軟性をはっきりと見ることができます。

SConsが完璧でなくても（ビルドシステムは何ですか？）、それで十分かもしれません。

• 必要な機能を提供していますか？
• どのくらいのオーバーヘッドが発生しますか？

SConsが両方のポイントで「十分に良い」と評価した場合は、それを維持します。

SConsを他のものに置き換えることを提案している人は、実際にGodotビルドシステムがどのように機能するかを学ぶために努力しましたか？

ヒントとして、これは非常に複雑であり、これほど多くのプラットフォームにCMakeビルドを使用し、複数のビルドターゲットを同時に構成/コンパイルできるプロジェクトは多く（またはまったく）ないと思います。

「Godotビルドシステムを他の何かに移植する」と言った人々のすべての努力は、SConsが処理しているものの複雑さに気付いたとき、これまでのところ惨めに失敗しました。

私にとって、それは仕事に最適なツールをはるかに受け継いでいます。 それに近いものはありません。 基本コンパイル時間（SSDを備えたミディアムからハイエンドのシステムではわずか4/5秒）について不満がある場合は、まず、Godotがビルド時に行うすべてのことを理解し、CMakeなどでどのように動作するかを確認する必要があります。 。

私は見てみました。 CMakeや他の場所で元に戻すことができるとは思いません。 しかし、私も怠け者です;）。 何が起こるか見ていきます。

バゼルポートをした人として。 Godotエディターがアイコンなしで開始するところまで到達することができました。

CMakeがそのポイントに到達できると確信しています。

PS。 大量のプラットフォームを使用する最も近い競合プロジェクトはUrho3dです。

ベーゼルの結果をcmakeで再現しました。

https://github.com/fire/godot/tree/cmake

Visual Studio2017がインストールされていると仮定します。

git clone https://github.com/fire/godot.git -b cmake
scons p=windows
Modify platform/register_platform_apis.gen.cpp
#include "register_platform_apis.h"

void register_platform_apis() {
}

void unregister_platform_apis() {
}

cmakeをインストールします

choco install cmake ninja -y
# Open visual studio command prompt amd 64 2017 native
# Go to godot source directory
cd ..
mkdir build
cd build
cmake ../godot -GNinja
ninja

遊んでください。 エディターには、bazelビルド（アイコンなし）と同じ問題がありますが、このサンプルが役立つ場合があります。

ノート

• アイコンは71175b45f819e7cc5e4368dbf3e42abdd19af542の時点で機能します
• ビジュアルスクリプトとGDscriptは機能します

@fireありがとうございます。 これらのCMakeファイルのメンテナンスを容易にする（そして新しい機能やコンパイラフラグの追加に費やす時間）改善の余地がたくさんあります。 私は来週末に取り組むかもしれませんが、スケジュールは保留中です。

素晴らしい仕事@fire。 ここで誰かが1つ以上のビルドシステムで何かを生み出すことができるのを見てうれしいです： smile:。

わずかな更新。 今日は、 @ fireの作業からの構築に取り組むためにダウンタイムがありました。 残念ながら、コード生成スクリプトはまだ現在のSconsシステムに少し埋め込まれすぎており、完全に解放するにはいくつかの作業が必要です（もちろん、これはコードを正しく読んでいることを前提としています）。 そうは言っても、それはおそらく別の問題+プルリクエストになるでしょう。 外部テンプレートファイル（または一連のテンプレートファイル）を使用できるいくつかの領域を特定しました。 Pythonはテンプレート文字列をサポートしている

理想的には、コード生成スクリプトは、ビルドの知識がなくても実行可能ファイルであるかのように実行できる必要があります。 適切なファイルがそれらに渡されている限り、他のビルドシステムに完全に移植することをお勧めします。

@ slurps-mad-rips SConsシステムからそれを取り除くことは、SConsでも良い考えです。 処理中のロジックが多すぎるとGILがハングアップし、ビルドのパフォーマンスが低下する可能性があります。 場合によっては、並行してビルドするときに、ファイルのクローズ/オープンの競合状態が発生することがあります（ただし、コンテキスト内でファイルを開くことで解決されることがよくあります）。

皆さんこんにちは、

このスペースを使用して、CMakeへのポートで人々を最新の状態に保ちます。 要求された場合は、別の問題を作成し、そこで変更を追跡しますが、これは議論の膨大なバックログがあり、多くのコンテキストを失うのは無駄だと思うので、これは素晴らしい領域です。

私は逸脱します。 会議に参加している間、来週はCMakeポートから休憩する必要がありますが、最初の移植の試みの取り組みはここで確認できCONFIGURE_DEPENDSグロブを持っていることは実際には非常に素晴らしいです。

最後に、他のCMakeプロジェクトを作成している場合、これらのモジュールが役立つ可能性があるという理由だけで、私が作成したヘルパーCMakeモジュールをぜひお試しください。

最新の3.1アルファ版にアップデートできましたか？ アルファは良いターゲットになる可能性があります。 現在ビルドを試みています。

この号のタイトルは、ビルドシステムをMesonに移動することを検討することです。 ここでCMakeの議論をするのは不適切だと思います。 CMakeについての議論にはそれ自身の問題があるはずです。 Mesonと他のものとの比較は問題ありません。

@zaniarこのスレッドでは、ビルドシステム全般に関して多くの議論がありました。 タイトルが更新されていないからといって、突然新しい問題を作成し、議論のためにそのコンテキストをすべて失い、最初からやり直すという意味ではありません。 数ヶ月分の議論を急に捨ててもらうのは不適切だと思います。

@fireここ数週間は仕事で忙しく、金曜日には大きな締め切りがあります。その後、フォークを最新の状態にするための時間がかかるかもしれません。 ローカルでいくつかの変更があり、プッシュするのを忘れましたが、今は時間がありません。 （このビルドシステムポート、gnu m4のフォーク、月の最後の週にサンディエゴのC ++標準会議とCppConのために書いている15の提案の間で、私は絶対に圧倒され、責任を負う人は誰もいません。私自身）

ええ、Mesonが最初のディスカッションのターゲットでしたが、それ以来、他のビルドシステムが取り上げられて議論されているのは当然だと思います。おそらく、@ slurpsのように、この問題を広めるのではなく、この問題の中で議論を続けるのが理にかなっています。 -mad-ripsは言った。

CMakeへの移行に同意します。 ツールチェーンで多くのサポートがあります。 たとえば、Androidのビルドは、GodotがSCsubファイルで実行していることと比較して非常に簡単になります。

オープンソースプロジェクトとして、Godotは、保守が容易で、貢献者が知り、貢献できる可能性が高いソリューションを採用する必要があります。

また、これはGDNativeの採用にとって重要だと思います。 どちらのビルドツールを使用する場合でも、iOS、Androidなどを含むすべてのプラットフォームのビルドをサポートする簡単に変更可能なビルドスクリプトを使用したサンプルまたは標準プロジェクトが必要です。

また、通常のモジュールは共有ライブラリとしてコンパイルできる必要があります。 これは＃19486に関連しているため、エンジンを複数のダウンロード可能なコンポーネントに分割できます。

私は実際にこれらに取り組んでいます。 来たるC ++標準会議であるCppConで忙しいので、しばらくの間、変更をプッシュしていません。来週、仕事でリリースを行う予定です。 言うまでもなく、移植を完了する時間はあまりありませんでしたが、私の時間のほとんどは、C ++コードを生成するPythonスクリプトをリッピングすることに費やされます。 今週末、自分のポートでの作業を再開したいと思っています。 現在、サードパーティの依存関係を自動的に取得して、リポジトリに保存されているパッチを適用するかどうかを評価しています。 コア開発者に対して私が持っている質問の1つは、すべてのサードパーティリポジトリをメインリポジトリから組織上の独自のリポジトリに分割することに対してどれほどオープンであるかということです。 私は自分のプロジェクトでFetchContentにかなり大きく依存しており、現在、わずかに分岐しているこれらのサードパーティの依存関係に対してそれができることを望んでいます。 これにより、各サードパーティライブラリが移植された後、コアリポジトリに段階的な変更を加えながら、 cmakeファイルをクリーンアップするために順番に作業することもできます。

さらに、エンジン自体もモジュール化しようとしているので、誰かが必要にできることに注意してください。 これは、 @ chanonが言及した問題をノックアウトする可能性があります。

最後に、コア開発者がシステム上で見つかった場合に、それらのビルドツールのサポートをいくつか追加します。 clang-format、clang-tidy、ccacheまたはsccache、distcc、clang-check、アドレスサニタイザー、ubsanitizer、スレッドサニタイザーなど。これらはほとんどがリンターです（警告やさまざまなエラーで頭が爆発する可能性があります）検出しています）が、有効にするのはオプションです。 少なくとも、sccacheまたはccacheを使用すると、ビルドを切り替えるときにビルドがある程度改善されます。その逆も同様です。 CMake 3.13がリリースされるのを待つことは、私が頼らなければならなかった厄介な作業の一部を解決するのでいいでしょうが、重要なことは、現在の「はじめに」ワークフローがPython 3.5以降を介してpip installを実行しますが、virtualenv内にあるため、システムの環境をいじる必要はありません。 （これにより、他の人がさまざまなコード生成スクリプトの依存関係として追加のPythonライブラリを使用して実験することもでき、後でそれらをアンインストールすることを覚えておく必要はありません）

とにかく、突然の情報ダンプを更新してすみません。 私はこのポートを完成させることに専念していますが、最近は人生が邪魔になっています😅

私は自分のプロジェクトでFetchContentにかなり大きく依存しており、現在、わずかに分岐しているこれらのサードパーティの依存関係に対してそれができることを望んでいます。

また、 Hunterを使用して、godot固有のコードリポジトリ（たとえば、githubなどの特別なgitリポジトリ）を作成し、必要に応じて適切にビルド、キャッシュなどを処理するときに、すべての依存関係にアクセスすることもできます。 （または、すべての依存関係を「メイン」ハンターパッケージリポジトリに送信し、そのまま使用します）。 Hunterは、単一のcmakeファイル（HunterGate.cmake）であり、パッケージリポジトリ情報（公式ファイルかカスタムファイルか）を取得するための呼び出しです。

謙虚なリクエスト：この問題のコメントスレッドは巨大になりました-それをフォローしている誰かがこれまでの一般的な議論をコメントで要約することができますか（そしておそらくそれは@RiverMesaの最初の投稿からリンクされる可能性があります）？

こんにちは、みんな。 小さなゲームを作るための次のエンジンとしてGodotを使用することを計画しています。

私はこの会話を見て、CMakeとMesonの両方（およびautotools、tup、plain make、waf、SCons、これらすべてのツールで完全なプロジェクトを試している...）の経験がある人としてフィードバックを提供したいと思いました。

私がより集中的に使用したシステムは、Autotools、CMake、Mesonです。 実稼働セットアップで他のすべてのビルドシステムをすでに破棄していたので、私は過去数年間MesonとCMakeを使用しています。

cmakeの長所

• Visual Studio（Mesonは最近はうまくサポートしていると思いますが、最近は試していません）、特にXCode（ここではもっと不足していることは間違いありません）に関心がある場合は、成熟したプロジェクトジェネレーターです。
• より幅広い採用、IDEでのより多くのサポート
• より幅広い採用->貢献を得るのがより簡単です（Mesonは私が言わなければならないことを学ぶのは簡単ですが）

中間子の長所

• デフォルトで多くの便利なターゲット：サニタイザー、無料のユニティビルド、無料のプリコンパイル済みヘッダー、無料のカバレッジ...
• ドキュメントはCMakeドキュメントからお尻を蹴り出します： http ：
• クロスコンパイルの方がはるかに簡単だと思いました
• Mesonには、それぞれのことを行うための明白な方法があります

どちらを選びますか？ クロスコンパイルが集中的になり、コンパイル時間が速いことが気になる場合は、Mesonを選択します（ユニティビルドとプリコンパイル済みヘッダーはデフォルトでサポートされています）。
CMakeは標準であり、チームにとって貢献が重要である可能性があるため、私はCMakeを検討します。 私は自分でMesonを選びますが、それは個人的な意見です。ツールの方が優れていて、自分の時間を節約できるからです（CMakeスクリプト、スペース処理、ジェネレーター式など...私はあなたを見ています）。

以下のこの恥知らずな自己宣伝については申し訳ありませんが、文脈はそれを懇願していると思います。

誰かが興味を持っているなら、私はここに多かれ少なかれ基本的な中間子についての小さなシリーズの記事を持っています（4つの記事）：

• https://medium.com/@germandiagogomez/getting -started-with-meson-build-system-and-c-83270f444bee
• https://medium.com/@germandiagogomez/getting -started-with-meson-in-c-part-2-58150354ff17
• https://medium.com/@germandiagogomez/getting -started-with-meson-in-c-part-3-70b9bc419957
• https://medium.com/@germandiagogomez/getting -started-with-meson-part-4-8bceec6149e1

StackOverflowのビルドシステムに（少し古くなった）返信があります：

https://stackoverflow.com/questions/5837764/autotools-vs-cmake-for-both-windows-and-linux-compilation/24953691#24953691

ちょうど私の2セント:)

@germandiagoこれは素晴らしい記事です-私はこの問題をしばらくフォローしてきましたが、悲しいことにCMakeのみであるgodot + CLionで作業できれば素晴らしいと思います。

ええ、ほとんどの最新のIDEは、CMakeのみ、または一部のカスタムビルドシステム、および/または多くの機能を失う「生の呼び出し」のいずれかです。 CMakeは、メリットがあるかどうかにかかわらず、本当に標準になっています。

@dorkbox私が取り組んでいるこれらの変更を取得できれば、CLion（cmake + ninja）ワークフローで間違いなく作業できるでしょう。

@germandiago

私は実際には（多かれ少なかれ😛）、CppCon 2018の時点で中間子の作者と友達になっています。「RemembertheFortran」というタイトルのモジュールに関する次回の会議で、私たちは両方とも同じ論文になりました。同会議での彼の論文（実際には来週です！）、そして私たちもCppConの同じビルドシステムパネルにいました。

Mesonを使いたいです。 スレッドをさらに読んでみると、私は中間子ポートを試していましたが、当時はSconsと統合されすぎていました。 将来、Mesonへの移行が問題にならないように、現在のコード生成スクリプトを個別の「実行可能」スクリプトに引き出しています。 ただし、作業が遅く、コード生成に役立ついくつかのjinjaテンプレートを作成して、sconsを完全に削除できるようにしました。 とは言うものの、私のパブリックフォークは古くなっていますが、自宅にあるフォークは少し先にあります（そしてプライベートフォークに同期されています）。 残念ながら仕事が邪魔になり、サンディエゴは残念ながら私の時間をもっと「盗む」ことになります。 ただし、その後は、プライベートフォークで行ったローカル実験の一部を自由に削除して、最終的にgodotcmakeトレインに戻る必要があります。 私は、現在のワークフロープロセスを大幅に中断することなく、完全なプルリクエストを確実に処理できるようにすることをお約束します。

（余談ですが、これに取り組んでいる間、皆さんの忍耐に感謝します。開始してからしばらく経ちましたが、現在はC ++標準委員会の米国国立機関の雇用主を代表しています。特にモジュール、コルーチン、範囲などの重要なトピックにぶつかったため、最近はもう少しいっぱいになっています）

ええ、ほとんどの最新のIDEは、CMakeのみ、または一部のカスタムビルドシステム、および/または多くの機能を失う「生の呼び出し」のいずれかです。 CMakeは、メリットがあるかどうかにかかわらず、本当に標準になっています。

IDEで中間子を使用するための可能な便利なツール：

https://github.com/prozum/meson-cmake-wrapper

IDEはCMakeを使用していると思わせますが、実際には内部でmesonを使用しています。

いくつかの背景：私は何年もの間（10？）CMakeの大きな支持者でしたが、昨年かそこらで中間子に恋をしました。 Mesonは、CMakeの煩わしさの多くを修正/防止しながら、CMakeの便利な機能を使用することを目的として作成されているようです。 プロジェクトで中間子を採用するために現在直面している障害の1つは、IDEのサポートです。 上記のツールを発見したばかりなので、おそらくそれが役立つでしょう。

すべてのビルドシステムには大きな欠陥があります。それ以上に、それを技術的な観点から変更する理由はありません。それは、scons、autotools、cmake、meson、またはあなたの宗教が何であれ、忍者です。 これと同じように、他のすべてのビルドシステム変更のバグを閉じるのは素晴らしいことだと思います。

<reduz> iFire: no, you did not, all you did was build it but did not port any of the dozens of custom scripts that generate code
<iFire> reduz: the other person worked on the little python script generation on her branch
<iFire> so they directly imported the python env
<iFire> it's workable
<reduz> iFire: that is what everyone said that attempted it, and failed :P
<reduz> there are too many things in there

reduzが間違っていることを証明してください@ slurps-mad-rips :)。

まだ言及されていない部屋の800ポンドのゴリラ。 Godotの名声の1つは、クロスプラットフォームの互換性です。 移行の可能性のあるビルドシステムはすべて、Godotが対象とするすべてのプラットフォームで利用可能でテストされている必要があります。 このような移行の背後にいる人は誰でも、サポートされているすべてのプラットフォームで移行をテストする傾向があるか、少なくともそうしているチームの一員である必要があります。 そうでなければ、私はそのような動きをGodotの哲学に反し、一般的には悪い考えだと思うでしょう。

@lazybullfrogデスクトップ用に約5台の個別のマシンと、いくつかのモバイルデバイスにアクセスできます。 私のcmakeへの移植の一部は、現在のすべてのプラットフォームで利用可能なcmakeツールチェーンがあることを確認することです。

@ slurps-mad-ripsそれらの俳句の1つですか？ そうでなければ、私はテストを手伝ってくれるでしょう。 ありがとう。

私のcmakeへの移植の一部は、現在のすべてのプラットフォームで利用可能なcmakeツールチェーンがあることを確認することです。

プラットフォームにcmakeツールチェーンが必要な場合は、おそらくhttps://github.com/ruslo/pollyにビルド済みのツールチェーンがあり、ない場合はPRする必要があることも忘れないでください。 :-)

@ slurps-mad-rips調子はどうですか？ 1月14日にコードを更新したことに気づきました。 Windowsでコンパイルしようとしましたが、pkgconfigが見つかりませんでした。

@fire lifeは私のやり方でいくつかのカーブボールを投げることに決めました、そして私はそれらの世話をしなければなりませんでした。 残念ながら、個人的なもの。 私は仕事に集中し、godotにコピーされる仕事の量を減らすために使用しているIXMライブラリを完成させてきました。 幸いなことに、私は1週間で休暇を取っているので（今週末の今四半期のWG21 ISO会議のためにコナに向かっています）、これに取り組むための暇な時間があります。 macOS、Linux、およびWindowssoon™用の動作するビルド。 その後、AndroidとiOS、続いてFreeBSDとHaiku（ @lazybullfrog 、申し訳ありませんが、早めに/頻繁にテストすることを歓迎します）が私の次の優先事項になります。

これまでの作業/ブロッカーの最大のチャンクは、Pythonスクリプトを、Sconとは別で、プロセスのように実行される「インストール可能な」ツールに抽出することでした。 依存関係や設定などの実際の取得は、比較して簡単になりました。

@ slurps-mad-rips、人生は私にもいくつかのカーブボールを投げました。 たぶん私たちは野球チームを始めるべきです。 😂

幸い、最後にコメントして以来、これらのカーブボールの1つは、HaikuとFreeBSDがインストールされた32GBのRAMを搭載した8コアのXeonでした。 おそらくすぐに、両方のテストを手伝う時間ができるでしょう。

私は実際、これらのプラットフォームの両方が注目を集めていることに恍惚としています。 すぐにテストするのを楽しみにしています。

複数のビルドシステムを持つことは合理的だと思います。 おそらく、十分にサポートされている公式のビルドシステムと、「あなたが理解した」ベースで提供されている他のシステムです。 ユーザーは関係なく独自のビルドシステムを使用したいと思うでしょう。それでは、作業を1か所にまとめてみませんか？

物事がそのように進んだら、私はBazelポートに貢献したいと思います。

複数のビルドシステムを持つことは合理的だと思います。 おそらく、十分にサポートされている公式のビルドシステムと、「あなたが理解した」ベースで提供されている他のシステムです。 ユーザーは関係なく独自のビルドシステムを使用したいと思うでしょう。それでは、作業を1か所にまとめてみませんか？

Linuxパッケージャーとして、私はさまざまなビルドシステムを使用した何百ものプロジェクトを見てきました。 いくつかのビルドシステムが利用できるものを見たことがあります。 特に、代替ビルドシステムが初めて「CMakeを追加してください」の貢献者によって提供され、その後プロジェクトから姿を消し、メンテナがわざわざ更新しなかった場合は特に、完全に混乱していないものを見たことがありません。

いくつかのビルドシステムをサポートすることにはまったく価値がなく、その方向に進むPRをマージすることはありません。 私は主要なbuildysytemメンテナーの一人であり、何かを変更する必要があるときはいつでも、代替のものを維持する負担を負いたくありません。

現在、すべての人に機能し、十分にサポートされており、変更する意図のないビルドシステムがあります。 誰かが本当に他のオプションを調査したい場合は、遠慮なく、最終結果がすべての人に有効であり、十分にサポートされ、大きな欠点なしに付加価値を提供できる場合は、それを検討します。

誰かが_本当に_他のオプションを調査したい場合は、遠慮なく、最終結果がすべての人に有効であり、十分にサポートされ、大きな欠点なしに付加価値を提供できる場合は、それを検討します。

それは私が私のCMakeポートでやってきたことです。 現在、sconsでのno-opまたは単一ファイルの変更は、現在のマシン（64GBのRAM、同等のプロセッサなど）で10秒以上かかります。ninja+ cmakeを使用すると、configure + generateプロセス全体にかかる時間が短縮され、ninjaビルドは、no-opビルドで0.2秒未満で完了します（プロセスの起動にコストがかかるWindowsの場合）。 インストールされている場合は、mozillaのsccacheツールを使用することもできます。これは、codegenパーツを編集したり、再生成されたビルドを最初から実行して、ローカル環境に依存しないことを確認するのに非常に役立ちます。

私の時間のほとんどは、コード生成スクリプトを、単独で実行できるPythonスクリプトに抽出することに費やされてきました。 それがgodotにマージされた唯一のものである場合、これに費やした私の時間は完全な無駄ではなかったでしょう。 また、並列化を使用したWindowsの問題を解決するために現在存在するrun_in_subprocessハックも解決します。

旅行から戻ったばかりで、ちょっとした仕事をすることができました。 今のところ、手動​​のscons実行からいくつかのファイルをコピーする必要がありますが、時間が経つにつれて、生成されたソースを削っています。 license.gen.hヘッダーとmethod_bind.incヘッダーが現在の私の最大のターゲットですが、時差ぼけと作業に取り組む前に、数日かかります。

（彼はこの進歩に少し興味を持っていたので、 @ fireもccするつもりです）

私の経験から、WindowsでAndroidを構築するとき、Mesonは完全にうんざりしています。それを使用するサードパーティライブラリの1つ（libepoxy）をコンパイルするためにMesonを動作させることができません。 そして、私はそれが具体的なコンパイラーのものにあまりにも結びついていると思います。

私が望むのは、buildコマンドとは別にプロジェクトファイルとデータベースファイルを生成できるビルドシステムだけです。

ファイルに大きな変更が加えられた新しいブランチをチェックアウトするたびに、コマンドラインからSconsを実行して、vsprojファイルを再生成する必要があります。これにより、とにかくフルビルドが発生します。 私が見たSconsには、いかなる種類のプロジェクト生成段階もありません。 これが、clang-toolsで使用するためのコンパイルデータベースの生成をサポートしていない理由でもあります。

現在、WindowsでGodotを（IDE単位で）コーディングするための唯一の実行可能なソリューションは、Visual Studioを使用することです。それ以外の場合は、テキストエディターを使用する準備をしてください。

Sconsは素晴らしいですが、12コアのスレッドリッパーと128 GBのRAMがあり、Windowsで1行の変更をコンパイルするために12秒以上待たなければならない場合（そのほとんどはSconsの考えです）、少し面倒になります。

しかし、Sconsの本当の欠点（そしてこれは検索の怠惰かもしれません）は、個々のcppファイルをコンパイルできないことです。 プロジェクト全体をビルドせずに個々のcppファイルをコンパイルできることは、生産性を大幅に向上させ、健全性チェッカーになります。

線の変更だけでなく、構築するものがあるかどうかを判断するのにも時間がかかります...

git-bashから実行：

$ time scons -j24 num_jobs=24 vsproj=true platform=windows
scons: Reading SConscript files ...
Configuring for Windows: target=debug, bits=default
 Found MSVC version 14.2, arch amd64, bits=64
YASM is necessary for WebM SIMD optimizations.
WebM SIMD optimizations are disabled. Check if your CPU architecture, CPU bits or platform are supported!
Checking for C header file mntent.h... no
scons: done reading SConscript files.
scons: Building targets ...
[Initial build] progress_finish(["progress_finish"], [])
[Initial build] scons: done building targets.

real    0m16.082s
user    0m0.000s
sys     0m0.030s

単一のターゲットファイルのみをビルドする場合は、コマンドラインでそれを指定します

scons -j24 num_jobs=24 vsproj=true platform=windows <path  to targetfile>/targetfile.obj

CMakeの最新バージョンは、使用しない理由として前述の不足している機能のいくつかを追加していることを付け加えたかっただけです。
Unityビルド： https ：
プリコンパイル済みヘッダー： https ：

@Nosliwnayrどちらも長年アドオンによってサポートされており、十分にテストされており、今では十分に含まれることを望んでいます。 非常に長い間CMakeで両方を行うことができたので、これらはCMakeを使用しない理由ではありませんでした。

@bdbaddog
わかりませんが、すべてのファイルを手動で具体的に指定する必要がありますか？ その.objのことは何をしますか？
プロジェクト全体に適用するにはどうすればよいですか？ 個々のファイルを自動的に再コンパイルしますか？

コンパイル時間をさらに最適化できることを願っています。トリックなしでほぼ​​瞬時にc ++コードをコンパイルできることは、神の送信です-godotのコンパイル速度を確認した後、非現実的なエンジン4に戻るのに本当に苦労しています（コンパイルする） 、45分かかりましたが、エンジンがどういうわけかもっと肥大化し、最大60分かかります。これは非常識です）

つまり、godotはさらに高速にコンパイルできる可能性があり、ビルドシステムを自分で置き換えると思いますが、経験がないので、文字通り何をすべきかわかりません。

@Nosliwnayr
プリコンパイル済みヘッダーを避けてもらえますか？ 私はそれらが完全なゴミだと思います、ただそれを単純にしてください

彼らはまた、共有プロジェクトを作成し、はるかに迷惑であり、それは私の心の中であまりにも多くの欠点を抱えて、膨満感を終わらせることはありません-しかし、誰かがそれらを効果的に使用した場合、私はクールですが、代わりにそれらは汚いトリックのように見えます真の最適化の、そして私は正直に言うと安いトリックが好きではありません

Unreal Engine 4を使用した後、20 GB相当のコンパイル済みのでたらめにうんざりしていますが、それだけの価値はないと思います。それほど愚かなシステムは必要ありません（Unreal Engine 4は最大60を要しました-私にとっては80GB、クールではありません）

godotがその方向に向かっている場合、開発者は彼らの神の気を失ったと思います

地獄、それをファック、私はむしろそれらをスコンに固執させたい、それが非現実的なエンジン4の狂気のボールを回避するなら、私はより賢いアプローチは、スコンを完全に置き換えるのではなく、まったく新しい壊れたお尻で改善することだと思いますコンパイルシステム、現在のものが機能するとき...多かれ少なかれ

まったく新しいシステムを導入するために必要な精神的な努力は、私たちがすでに持っているものを改善するだけでなく、はるかに高いと思います。新しいコンパイラは、数か月間機能的に壊れてしまう可能性があります。

それが終わっても地獄は文句を言うつもりはないのは確かですが、そのような重要なエンジンコンポーネントでは、ほとんどすべてを入力する必要があります。これが変更されると後戻りすることはありません

@ RaTcHeT302-指定されたコマンドラインは、単一のターゲット（この場合はオブジェクトファイル）（およびもちろんそれが依存するファイル）のみを明示的にコンパイルする場合です。

確かに、SConsの問題について不平を言っているすべての人々が、複雑なビルドシステムを別の新しいより光沢のあるものに切り替えることを提案するのではなく、SConsの修正に貢献するのであれば、そのような懸念の多くは修正されます。

@bdbaddog Sconsは、中間段階のビルドファイルを生成しません。 コンパイルと同じステップで「プロジェクトの依存関係」ステップを実行し、それらを分離することはできません。

これは、MSVC、ninja-build、make、llvm、ポイズンの選択など、ビルドツールを実行する前に毎回プロジェクトファイルを生成するようにCMakeに指示するようなものです。

gitブランチを切り替えると、sconsコマンドラインビルドを実行して適切な.vsprojファイルと.slnファイルを再生成しないとVisual Studioを更新できません。また、過去に問題が発生したため、ほとんどの場合、ビルドブランチの変更をクリーンアップしています。

これらの中間ファイルはビルド専用ではなく、静的アナライザーやその他のプロジェクトでも使用できます。

私はcmakeが完璧ではないことに同意し（私自身はあまり好きではありません）、Pythonの柔軟性を好みますが、cmakeはテーブル上のすべてのビルドツールの中で最高の統合とサポートを備えています。

私のフォークをCMakeに変換するとき、複雑さのほとんどはコード生成ファイルにありました。 ビルドが複雑であるという考えは誤りです。 ビルドは複雑なので、sconsは必要ありません。 sconsを使用しているため、複雑です。

そうは言っても、私が仕事をやめた理由は、2019年にGDCで（GitHubミートアップで）リード開発者と会い、彼らがもっと使いやすいものに切り替えるつもりはまったくないと言ったからです。ビルドは完全にLinuxで行われ、実際、私が見たところ、クロスコンパイル用のビルドツールをインストールするためにAppleが承認を要求するEULAに違反しています。

担当者のメンタリティは非常に「手段を正当化する目的」であり、ビルドをソフトウェアとして扱うことに関心がないようです。代わりに、godotはビルドを生成する一連のスクリプトとして扱います。

コード生成に加えた変更をgodotに提供することはありません（読みやすく高速であるにもかかわらず）。このエンジンを完全に諦め、人生を歩み続​​けました。 正直なところ、私はずっと幸せです。 エンジンにはすでにかなりの技術的負債があり、特にC ++標準委員会がツールのテクニカルレポートに取り組んでいるため、約3年で問題になると思います（私はこれに関与しており、オプションファイルの標準化などを推進していますある程度ですが、これは単なるテクニカルレポートであるため、一部の人々はそれから逸脱します）。

それも残念です。 私のCMakeビルドは、多くの問題を引き起こし、簡単に解決できる静的分析エラーの束をキャッチすることができましたが、GDCでこれについて開発者と議論したことで、バグを報告したり、修正を試みたりすることさえできませんでした。彼ら。 私のエネルギーとメンタルヘルスは他の場所でよりよく使われます。

多くのツールを壊す方法を私が叫んだ限り、sconsが今後のC ++ 20モジュールの設計を処理できる世界はありません。 そのための依存関係の追跡を処理することはできず、プレスキャンステップが必要になります。これにより、依存関係の追跡がさらに遅くなります。

最後に、小さな変更しか受け入れられないツールを改善しようとしないことをお勧めします。 Sconsは、ここの人々が求める改善を得るために、ゼロからの完全な書き直しと多数の重大な変更を必要とします。

ビルドシステムの変更に関する議論がGDC2019で回答されたため、この問題を解決することをお勧めしますが、リードはこの問題についてコメントするのに時間を無駄にする価値さえないと考えています。これは、人間工学にどれほど関心があるかを示していると思います。開発の。

既存のビルドシステムがプラグアンドプレイ方式で100％変換されたかのように、開発者が切り替えない理由はないだろうと思います。

Linux上でのみ構築することは無意味です。 Windows上で実行されないゲームエンジンを持つことは、シリアスゲーム開発者を思いとどまらせるでしょう。

ゲーム開発者は、ユーザーを満足させるためにビルドシステムを変更するのに十分気を配っているという印象を受けたいと思います。

私がUnrealを離れた理由の1つは、エンジンが主にブループリント/フロントエンドゲームの作成用に調整されていることです。 Unrealでは、C ++モジュールでツールを作成するのは非常に面倒で複雑です。

これまでのところ、Godotではそれはまともな快適さでした。 C ++ビルドを高速化することは、コミュニティにとって大きなプラスになります。

IIRCは、Wineを使用してMSVCビルドツールを実行します。 それでもあなたの主張は変わりません、そして私は同意します。

Linux上でのみ構築することは無意味です。 Windows上で実行されないゲームエンジンを持つことは、シリアスゲーム開発者を思いとどまらせるでしょう。

Godotは、Linuxだけでなく、多くのプラットフォームで常に構築可能です…

IIRCは、Wineを使用してMSVCビルドツールを実行します。 それでもあなたの主張は変わりません、そして私は同意します。

公式のWindowsビルドはMinGWを使用してコンパイルされます。 LinuxでMSVCを実行するためにWINEを使用することはありません。

@ marstaik -MSVSプロジェクトファイルを生成するためだけにビルドを切り替えてsconsを実行する場合は、それらのファイルをターゲットとして指定でき、完全なビルドを実行する必要はありません。

だから試してみてください：

scons <path to created MSVS project file>/VSPROJECTFILENAME (replace with actual paths and file name which are generated)

SConsは、完全なビルドを実行しなくてもこれを実行できる必要があります。また、最初にクリーンアップを実行しなくても正しく実行できるはずです。
（ところで、私はSConsプロジェクトのメンテナーです）

@bdbaddogそのコマンドにvsproj = Trueを追加する必要がありましたが、機能したようです

godot srcから：
scons -j24 godot.vxcproj num_jobs=x vsproj=true

編集：何らかの理由で、-jフラグも追加する必要があります...

@bdbaddogそのコマンドにvsproj = Trueを追加する必要がありましたが、機能したようです

godot srcから：
scons -j24 godot.vxcproj num_jobs=x vsproj=true

編集：何らかの理由で、-jフラグも追加する必要があります...

このようなフラグの多くはバニラSConsではありませんが、さまざまなパッケージ（この場合はGodot）がSConsを使用してビルドシステムを実装する方法の一部です。
道を見つけてよかった！

なぜSConstructを使用し、他のビルドシステムに切り替えないことを主張するのですか？

@tjysdsg上記の議論は、それを非常にうまくまとめています：slightly_smiling_face：

ビルドシステムを事前に変更する意図がないことを何年にもわたって明らかにしてきたので、これを閉じます。 私たちはSConsに満足しており、その欠点は、私たち自身のSConsの使用内と、ツール自体が原因である場合はアップストリームの両方で、個別に評価することができ、評価する必要があります。

それのために「より涼しい」ビルドシステムに切り替えることは起こりません。 コアコントリビューターの大多数はSConsの使用に満足しており、これが現在私たちが最もよく知っているものです。 新しいビルドシステムへの切り替えには、実装と学習の両方のコストがかかり、それらが問題を起こす価値があることは今のところ証明されていません。

全体として、ビルドシステムの変更は、新しい貢献者から受け入れるものではありません。 それは内側から来なければならず、すべての主要な貢献者はそれが意味をなすためにそれを前向きな変化として見なければなりません。 私たちは、ソースからゴドーを構築しようとすると、何らかの形で行う新しいユーザーを喜ばせるためだけのビルドシステムを変更しないではない、彼らは入力する必要があることのようにsconsの代わりにcmakeまたはmeson彼らが慣れている

もちろん、ビルドシステムを変更するコストを上回る明確な利益をリストする（そして概念実証を示す）ことができれば、私たちは考えを変えることができますが、今日とここでの2年間の議論の後、私は個人的にインセンティブがわかりません。

@ slurps-mad-ripsはそれをうまく言った。

sconsを使用しているため、複雑です。

と

私のCMakeビルドは、多くの問題を引き起こし、簡単に解決できる静的分析エラーの束をキャッチすることができました

CMakeのを真剣に検討を与えられていないことを嫌なフラットアウトは、私はcmakeのはsconsのは、それが「価値が、それは」何か他のものを使用することができますを見つけることができませんエラーを検出特異的に溝のSConsはに多くの理由を考えることができますが。

それのために「より涼しい」ビルドシステムに切り替えることは起こりません

CMakeは「クーラー」ではなく、標準です。 実際に使ってみれば、その理由がすぐにわかります。

もちろん、ビルドシステムを変更するコストを上回る明確な利益をリストする（そして実用的な概念実証で示す）ことができれば、私たちは考えを変えることができます。

私は誰もが自分の考えを変えることにオープンであるとは確信していません。 繰り返しになりますが、@ slurps-mad-ripsは明らかな利益を示し、彼女はすべての作業を行いました...それはすでに完了しています。

Godotチームの公式の立場を代表して、開発プロセスを改善する彼女の努力を完全に無視することは恥ずべきことです。

私はあなたの痛みを完全に理解していますが、それでも他の人に同意します-すべてのビルド
システムには
長所と短所、そして一般的に同じ。 技術的な理由はめったにありません
それを変更します。
政治的な理由で、彼らはあなたに長い間良いことを何もしません
走る。 みんな
何か違うものを好む。 とにかく誰もフォークをするのを止めません
何でも
理由があるので、これは他のどれよりも優れていると思います。

金、2020年2月21日に13:38でdorkboxの[email protected]は書きました：

@ slurps-mad-ripshttps ：//github.com/slurps-mad-ripsはそれをうまく言いました。

sconsを使用しているため、複雑です。

と

私のCMakeビルドは、静的分析エラーの束をキャッチすることができました。
たくさんの問題を引き起こし、簡単に解決できます

CMakeが真剣に考慮されていないのは嫌なことですが、私はできます
SConsはを捨てるために多くの理由を考える、が、特にCMakeのを見つけました
Sconsが検出しないエラーは、他のものを使用する価値があります。

それのために「より涼しい」ビルドシステムに切り替えることは起こりません

CMakeは「クーラー」ではなく、標準です。 あなたが実際にそれを使用した場合、あなたは
理由をすぐに理解してください。

もちろん、明確な利益を挙げられれば、私たちは考えを変えることができます。
（そして概念実証で示されている）
ビルドシステムの変更

私は誰もが自分の考えを変えることにオープンであるとは確信していません。 また、
@ slurps-mad-rips https://github.com/slurps-mad-ripsは明らかな増加を示しました、
そして彼女はすべての仕事さえしました...それはすでに行われました。

Godotチームの公式スタンスを表すのは恥ずべきことです
開発プロセスを改善する彼女の努力を完全に無視します。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ
。

@ dorkbox -cmakeは静的分析エラーを見つけましたか？ それとも、cmakeから出力されたコンパイルデータベースがllvmの静的分析ツールを介して実行されたのでしょうか？

@ bdbaddog 、@

@slapin

それを変更する技術的な理由はめったにありません。

静的分析ツールと最新の言語機能のサポートはどうですか？

@bdbaddog @dorkbox単にclang-tidyをオンにして、CMakeを介して「非静的ローカルへの参照を返す」や「バッファオーバーフロー」などを探しました。 また、いくつかの点でclang-checkを実行し、さらにいくつかの結果を得ました。 include-what-you-useも実行することができ、かなりの数の不要なヘッダーが含まれていることがわかりました。

そうは言っても、私は実際にはcmakeポートを「終了」しませんでした。 移植されなかった部分は、JSONからファイルを生成するためにいくつかのファイルでf.writeを呼び出すだけの現在のPythonスクリプトを変更しようとして行ったすべての作業

ただし、sconsビルドとの同等性を維持し、少なくともコード生成への変更をマージすることを望んでいました。ソースファイルの生成に使用されるPythonスクリプトは絶えず変更されており、それらの変更の同期を維持しているため、これは起こりませんでした。私のjinja2でのテンプレート化は、欲求不満の練習でした。

GDC GitHubのミートアップでリード開発者から得た非常に強調された難しい「いいえ」を考慮して、私はもはやgodotに貢献したくないと判断しました。 私の変更は望ましくなく、望まれず、この問題に関する他の人の意見に無関心です。 私はgodotにもgodotのフォークにも貢献しません。 リード開発者にこの問題を納得させようとする幸運を祈っていますが、それはレンガの壁に話しかけるようなものです。 このスレッドのすべての人の窮状に屈服せず、動かせず、無関心です。

したがって、SConsがllvmツールに入力されるコンパイルデータベースを吐き出すことができれば、これはSConsからも実行できます。

したがって、SConsがllvmツールに入力されるコンパイルデータベースを吐き出すことができれば、これはSConsからも実行できます。

SConsで起こっている埋没費用の誤謬があるようです。 cmakeのように、より簡単で合理化され、既存のビルドツールの一部であるものを使用してみませんか？

sconsのWebサイトから：

sconsと比較すると、CMakeは次のとおりです。

• もっと早く
• 一般的なタスクに必要なコードが少なくて済みます
  
  
  
  • 間違いなくより安定
  
  
  • sconsがサポートしていないCode :: Blocks、Xcodeなどのプロジェクトへの出力をサポートします
  
  

@ dorkbox-私はSConsプロジェクトの共同マネージャーです。 必要な機能に注目しています。

最近のいくつかのリリースと次のリリースでは、パフォーマンスが向上しています。

さらに、忍者ファイル生成用のPRがあり、一部のコミュニティメンバーにはコンパイルデータベースツールがあります。 したがって、いくつかの問題は、次のリリースで（完全ではないにしても、少なくとも部分的に）対処される可能性があります。

私たちが取り組んでいないgodotプロジェクトに影響を与える安定性の問題を私は知りません。 未解決のものがあればお知らせください。
（https://scons.org/contact.htmlからお問い合わせください）

cmakeが実際に一般的なタスクに必要なコードが少ないかどうかはわかりませんが、合理的な比較に興味があります。

さて、主にスコンで私を悩ませているのは、普通の古いものを生成できないことです
GNU makemakefile。 忍者の欠如-私はそれと一緒に暮らすことができます。
CMakeツールチェーンやautotoolsなどのクロスコンパイルユーティリティの処理も
クロスコンパイル機能は、cmakeの長所です。
私はIDEの人ではないので、残りは大丈夫です。 私のIDEはUNIX環境です。

22:05ウィリアムDeeganの日、2020年2月23日には[email protected]
書きました：

@dorkboxhttps ：//github.com/dorkbox-私はSConsプロジェクトの共同マネージャーです。
必要な機能に注目しています。

過去数回のリリースと次のリリースでパフォーマンスが向上しました
改善。

さらに、忍者ファイル生成といくつかのコミュニティのPRがあります
メンバーはコンパイルデータベースツールを持っています。 したがって、いくつかの問題が発生する可能性があります
次のリリースで（完全ではないにしても、少なくとも部分的に）対処される予定です。

私たちが行っているgodotプロジェクトに影響を与える安定性の問題を認識していません
対処していません。 未解決のものがあればお知らせください。
（https://scons.org/contact.htmlからお問い合わせください）

cmakeが一般的なタスクに必要なコードが本当に少ないかどうかはわかりません。
合理的な比較に興味があります。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ
。