私は何年にもわたってメイクとメイクファイルを使用してきました。コンセプトは健全ですが、実装には何かが必要です。
問題を過度に複雑にしないための良い代替案を見つけた人はいますか?
mike511
質問する
52172 次
12 に答える
31
SConsをチェックしてください。たとえば、Doom 3 と Blender はそれを利用しています。
于 2008-09-15T20:51:09.727 に答える
27
私には、クロスプラットフォーム開発のために CMake を誓う友人がたくさんいます。
これは、クロスプラットフォームの Python、Tcl、および Java バインディングを備えた C++ ライブラリであるVTK (とりわけ) に使用されるビルド システムです。これほど多くの機能がある中で、おそらく最も単純なものだと思います。
いつでも標準のautotoolsを試すことができます。Unix のみで実行していて、C/C++ に固執している場合、Automake ファイルをまとめるのは非常に簡単です。統合はより複雑で、autotools はこれまでで最も単純なシステムとはほど遠いものです。
于 2008-09-15T20:58:47.633 に答える
21
doitはPythonツールです。これはビルドツールの概念に基づいていますが、より一般的です。
- タスク/ルールがどのように最新であるかを定義できます（タイムスタンプをチェックするだけでなく、ターゲットファイルは必要ありません）
- 依存関係は他のタスクによって動的に計算できます
- タスクのアクションは、Python関数またはシェルコマンドにすることができます
于 2012-03-30T03:51:48.720 に答える
16
一部の GNOME プロジェクトはwafに移行しています。
これは Scons のように Python ベースですが、スタンドアロンでもあります。そのため、他の開発者にお気に入りのビルド ツールをインストールするよう要求するのではなく、スタンドアロン ビルド スクリプトをプロジェクトにコピーするだけです。
于 2008-09-15T20:59:03.887 に答える
7
およびのninja影響を受けるビルドツール（v1.8.2 2017年9月）に注意してください。tupredo
ビルドファイルジェネレーターcmake（たとえば、Unix Makefiles、Visual Studio、XCode、Eclipse CDTなど）もninjaバージョン2.8.8（2012年4月）以降のビルドファイルを生成でき、afaikは、ninjaで使用されるデフォルトのビルドツールですらありますcmake。
ツールよりも優れたパフォーマンスを発揮するはずmakeです（依存関係の追跡が向上し、並列化もされています）。
cmakeすでに確立されたツールです。構成ファイルを変更せずに、後でいつでもビルドツールを選択できます。したがって、将来サポートされるより良いビルドが開発されたcmake場合は、便利に切り替えることができます。
c / c ++の場合、プリプロセッサを介してヘッダーが含まれているため（特に、 boost＆eigenなどのヘッダーのみのライブラリを使用している場合）、コンパイル時間が制限されることがあります。これは、モジュールの提案に置き換えられることを願っています（技術レビュー） c++11または最終的にはc++1y）。この問題の詳細については、このプレゼンテーションを確認してください。
于 2013-03-21T14:47:21.407 に答える
5
makefile のようなものを非常に読みやすく、書きやすくするための、 sakeというツールを書きました。
于 2014-01-08T19:13:21.117 に答える
4
それは、あなたが何をしようとしているかに依存します。Make スタイルのターゲット依存関係とコマンド呼び出しだけが必要な場合は、実際には Make がそのタスクに適したツールの 1 つです。:-) Rake は非常に優れていますが、いくつかの単純なケースでは扱いにくい場合があります。Ant はもちろん冗長な都市ですが、Java に似た言語 (Scala と Groovy を含む) の構築をより適切にサポートしています。また、Ant はどこでも利用できます。それが私がそれを使用する主な理由です。Windows 上で一貫して動作するため、実際には Make よりもさらにクロスプラットフォームです。
Java ライクなライブラリの依存関係管理が必要な場合は、Maven が標準的な選択肢ですが、個人的には Buildr の方がはるかに優れています。カスタマイズがより速く、はるかに簡単です (Rake に基づいています)。残念ながら、まだ Maven ほど普及していません。
于 2008-09-15T20:56:10.523 に答える
3
たくさんの代替案を検討した後でも、私はまだ make を好みます。コンパイラまたは fastdep のようなものを介して依存関係を自動生成した場合、やるべきことはあまりありません。特に、ビルド スクリプトを実装言語に結びつけたくありません。また、より読みやすい代替手段が利用可能な場合に、XML で何かを記述するのは好きではありません。ただし、汎用言語を公開するツールにはメリットがありますが、さらに別のインタープリター言語にはメリットがありません (afaik)。 Makeの何が問題なのですか? makeから離れることについてのあなたの視点に訴えるかもしれません。
/アラン
于 2008-09-15T21:25:53.603 に答える
2
Ruby の make システムは rake と呼ばれます: http://rake.rubyforge.org/
非常に有望に見えます。
常に Ant: http://ant.apache.orgがあり、個人的には恐ろしいと思います。ただし、これは Java 開発の事実上の標準です。
于 2008-09-15T20:50:52.223 に答える
1
RTDAのFlowTracerは、大規模な環境（数万のジョブ）で商業的に使用されていることを私が見たもう1つの良い選択です：http ：//www.rtda.com/flowtracer-design-flow-infrastructure-software
これには、ジョブの色分けされたボックスとファイルの楕円を含む依存関係グラフを表示するGUIがあります。ジョブとファイルの数が多くなると、FlowTracerのようなGUIベースのツールが非常に重要になります。
初期設定費用はMakeよりも高くなります。それを使用して最初のフローを設定するための学習曲線があります。その後、それは速くなります。
于 2012-05-29T23:05:08.190 に答える
0
ここで正しい質問をしているかどうかはわかりません。
あなたは単純化されたメイクを求めていますか？その場合、問題を単純化する一連の (M|m)akefile を作成するために、make に精通している人を雇う必要があります。
それとも、基礎となるテクノロジーを見たいですか？コード設計に組み込まれて強制される、契約による設計タイプのアーキテクチャを強制したいですか? それとも言語自体、例えば Ada とその仕様 (インターフェース) と本体 (実装) の概念ですか?
あなたが求めている方向は、そのような質問の潜在的な結果に確実に影響しますか?
基本的には、実際に変更されたコンポーネントのみからシステムを構築する新しい方法と、そのようなメカニズムが設計によって組み込まれている新しいテクノロジーの採用です。
直接の回答でなくてすみません。どの道を進みたいかを評価してもらいたかっただけです。
乾杯、
ロブ
于 2008-09-15T21:02:42.397 に答える