10

(makefile ジェネレーター ツールの有無にかかわらず) 古い Make をビルド ツールとして目立たせるには、どのような力が働いているのでしょうか? 代替案が広く採用されるのを妨げているのは、代替案の欠陥なのか、それとも宣伝が不十分なのか、それとも Make の何かがそれを維持しているのでしょうか?

Make には多くの弱点があり、大規模なプロジェクトに対処するのが困難ですが (たとえば、http ://freshmeat.net/articles/what-is-wrong-with-make を参照)、 Sconsなどの新しく改良された代替手段よりも、まだ広く使用されているようです。ジャム、レーキ、クックなど。

代替手段には測定可能な利点がありますか?それとも、「市場シェア」は主にチーム リーダーの意見と経験によるものですか?

4

8 に答える 8

9

ユビキタス: 私がMakeを気に入っているのは、必要な場所 (ターゲット マシンにインストールされているか、簡単にインストールできる) で利用できると信頼できるからです。

于 2010-01-13T20:14:19.357 に答える
5

あなたの質問に関して、どの力が生き続けているのか...それは習慣の力です。

于 2010-01-13T20:15:29.493 に答える
1

makeの代わりに比較的大規模なプロジェクトでsconsを使用しましたが、それはかなり柔軟なシステムであり、必要な方法で構築するために非常に必要な（ただし非常に残念な）ハッキングを行うことができました。また、makeは-strange-です。

于 2010-02-10T02:44:37.120 に答える
1

多数のプラットフォームで利用できることは、おそらく役に立ちます。複数のプラットフォーム向けの製品を作成する場合、それが常に存在することを知っていることには利点があります。独自のプロジェクトをビルドする前に、ビルド ツールを新しいプラットフォームに移植しなければならないのは面倒です。

于 2010-01-13T20:15:20.900 に答える
1

うーん、makeビルドシステムとして使用したことはありません。

それ以外は、独自のデータフロー プログラミング言語であり、それぞれが特定の目的を果たす一連のノードを記述し、それらの動作を記述し、マネージャーがそれらの間のデータ フローを処理および制御できるようにします。

于 2010-01-14T05:23:04.143 に答える
0

別のツールへの大きな移行を確認するには、最初にツールを作成する必要があると思います....それは大幅に優れています。変更に影響を与えるには、Linuxディストリビューションの1つまたは主要なパッケージの1つをそれに切り替える必要があり、おそらく互換性のために古いものを保持する必要があります. 新しいビルド ツールは従来のメイクファイルを生成できると思います。Linux は、git を使用してソース コード管理システムをどれだけうまく解決できるかを既に示しています。私は、彼がかなりクールなものを考え出し、git と結び付けることができるというかなり良い予感を持っています。

于 2011-05-05T06:27:57.837 に答える