有望な代替案はありますか？[閉まっている]

私は長年makeとmakefileを使用しており、コンセプトは健全ですが、実装には望ましいものがあります。

問題を過度に複雑にしないための良い代替案を誰かが見つけましたか？

SConsをチェックしてください。たとえば、Doom3とBlenderはそれを利用しています。

クロスプラットフォーム開発のためにCMakeを誓う友人がたくさんいます。

http://www.cmake.org/

これは、（とりわけ）VTKに使用されるビルドシステムであり、クロスプラットフォームのPython、Tcl、およびJavaバインディングを備えたC ++ライブラリです。おそらく、これほど多くの機能を備えた最も複雑でないものだと思います。

あなたはいつでも標準のautotoolsを試すことができます。Unixでのみ実行していて、C / C ++に固執している場合、Automakeファイルは非常に簡単にまとめることができます。統合はより複雑であり、autotoolsはこれまでで最も単純なシステムとはほど遠いものです。

doitはPythonツールです。これはビルドツールの概念に基づいていますが、より一般的です。

• タスク/ルールがどのように最新であるかを定義できます（タイムスタンプをチェックするだけでなく、ターゲットファイルは必要ありません）
• 依存関係は他のタスクによって動的に計算できます
• タスクのアクションは、Python関数またはシェルコマンドにすることができます

GNOMEプロジェクトのいくつかはwafに移行しています。

これはSconsのようにPythonベースですが、スタンドアロンでもあります。したがって、他の開発者にお気に入りのビルドツールをインストールする必要はなく、スタンドアロンのビルドスクリプトをプロジェクトにコピーするだけです。

Rakeの使用をお勧めします。それは私が見つけた最も簡単なツールです。

ただし、Rubyがあなたのものでない場合、私が使用した他の優れたツールは次のとおりです。

• AAP（Python）
• SCons（Python）
• Ant（Java、XMLでの構成、かなり複雑）

およびのninja影響を受けるビルドツール（v1.8.2 2017年9月）に注意してください。tupredo。

ビルドファイルジェネレーターcmake（Unix Makefiles、Visual Studio、XCode、Eclipse CDTなど）もninjaバージョン2.8.8（2012年4月）以降のビルドファイルを生成でき、afaikninjaは現在でもデフォルトのビルドツールとして使用されています。cmake。で。

makeツールよりもパフォーマンスが優れていると考えられます（依存関係の追跡が向上し、並列化されます）。

cmakeはすでに確立されたツールです。構成ファイルを変更せずに、後でいつでもビルドツールを選択できます。したがって、より良いビルドが将来開発された場合、それはによってサポートされますcmake場合は、便利に切り替えることができます。

c / c ++の場合、プリプロセッサを介してヘッダーが含まれているため（特に、boost＆eigenなどのヘッダーのみのライブラリを使用している場合）、コンパイル時間が制限されることがあります。これは、モジュールの提案に置き換えられることを願っています（テクニカルレビュー） c ++ 11または最終的にはc ++ 1y）。この問題の詳細については、このプレゼンテーションを確認してください。

makefileのようなものを非常に読みやすく書きやすくしようとするsakeというツールを書きました。

それはあなたが何をしようとしているのかによります。場合は、すべてあなたがしたいが、メイクスタイルのターゲットの依存関係とコマンド呼び出しで、その後、メイクは実際には、タスクのためのより良いツールの一つです。:-)熊手はとてもいいですが、いくつかの単純なケースでは不器用になることがあります。Antはもちろん冗長な都市ですが、Javaのような言語（ScalaとGroovyを含む）の構築をより適切にサポートしています。また、Antはどこでも利用できます。それが私がそれを使う主な理由です。Windowsで一貫して動作するため、実際にはMakeよりもさらにクロスプラットフォームです。

Javaのようなライブラリの依存関係管理が必要な場合は、Mavenが標準的な選択肢ですが、個人的にはBuildrの方がはるかに好きです。カスタマイズがより速く、はるかに簡単です（Rakeに基づいています）。残念ながら、まだMavenほどユビキタスではありません。

Rubyのmakeシステムはrakeと呼ばれます：http：//rake.rubyforge.org/

非常に有望に見えます。

Antは常に存在します：http：//ant.apache.org、私は個人的に恐ろしいと思います。ただし、これはJava開発のデファクトスタンダードです。

たくさんの選択肢を検討した後でも、私は作ることを好みます。コンパイラーまたはfastdepのようなものを介して依存関係を自動生成する場合、やるべきことはあまりありません。特に、ビルドスクリプトを実装言語に結び付けたくないし、より読みやすい代替手段が利用できるときにXMLで何かを書くのも好きではありません。汎用言語を公開するツールにはメリットがありますが、さらに別のインタープリター言語にはメリットがありません（afaik）。 Makeの何が問題になっていますか？makeから離れることについてのあなたの視点にアピールするかもしれません。

/アラン

RTDAのFlowTracerは、大規模な環境（数万のジョブ）で商業的に使用されているのを私が見たもう1つの良い選択です：http：//www.rtda.com/flowtracer-design-flow-infrastructure-software

ジョブの場合は色分けされたボックス、ファイルの場合は楕円形の依存関係グラフを表示するGUIがあります。ジョブとファイルの数が多くなると、FlowTracerのようなGUIベースのツールが非常に重要になります。

初期設定費用はMakeよりも高くなります。それを使用して最初のフローを設定するための学習曲線があります。その後、それは速くなります。

ここで正しい質問をしているのかどうかはわかりません。

あなたは単純化されたメイクをしたいですか？その場合、makeに精通している人に、問題を単純化する一連の（M | m）akefileを作成してもらう必要があります。

それとも、基盤となるテクノロジーを見たいですか？コード設計に組み込まれ、適用される契約による設計タイプのアーキテクチャを適用したいですか？あるいは、言語自体、たとえばAdaとその仕様（インターフェース）および本体（実装）の概念？

あなたが求めている方向は、そのような質問の潜在的な結果に間違いなく影響しますか？

基本的に、実際に変更されたコンポーネントのみからシステムを構築する新しい方法と、そのようなメカニズムが設計によって組み込まれている新しいテクノロジーの採用。

申し訳ありませんが、それは直接の答えではありません。どの道を進みたいかを評価してもらいたかっただけです。

乾杯、

ロブ