ビルドツールが、基礎となるプログラミング言語とは異なるスクリプト言語を使用するのはなぜですか？

私は最近、ほとんどの言語のメインビルドツール/システムが基礎となるプログラミング言語自体とは異なる言語を使用していることに気付いたときに、Nodejsプロジェクトのビルドツールを使用しています。

たとえば、makeはCまたはC ++を使用してスクリプトを記述せず、ant（またはMaven）はスクリプトの言語としてJavaを使用しません。

Rubyのような新しい言語は、rakeのようなビルドツールに同じ言語を使用します。しかし、なぜこれが常に当てはまらないのですか？基礎となる言語とは異なる言語を使用するビルドツールを持つことの利点は何ですか？

何を行うためにどのプログラミング言語を使用するかの選択は、そのプロジェクトに関連する他のタスクではなく、その目標の特定の機能に依存する必要があります。

ビルドツールは非常に具体的な作業を行い、メインプロジェクトで使用する言語に関係なく、ビルドツールはそれ自体がソフトウェアです。

メインプロジェクトとそのビルドツールを結び付けようとすることは、非常に悪い決断になる可能性があります。ビルドツールに必要なのは、主にファイルとIOの高速管理を備えた、単純なルールの高速プロセスです。

rubyのような言語がビルドツールを実装するために自分自身を使用する場合、すべてが同じ言語で記述されていると想定される必要性よりも、その言語の機能に関連しています。

CやJavaなどの言語をスクリプト言語として使用するビルドツールを作成することは不可能ではありません。ただし、ビルドツールには、より宣言的なスクリプト言語を使用することによるメリットがあります。Cでmakefile（またはbuild.xmlなど）を作成する苦痛と定型句を想像してください。

ビルドツールは、DSLの使用から恩恵を受けます。DSLは、Cが特に良い選択ではないタスクです。Cはビルドツールには一般的すぎて、エラーが発生しやすい低レベルの詳細にあまりにも関心があります。たとえば、ビルドツールでの明示的なメモリ管理を気にする必要はありません。Cのような構文を使用している場合でも、スクリプトツールでガベージコレクションを使用している可能性があります。その時点で、単に専用のDSLを使用しないのはなぜですか。

RubyはCやJavaよりも高レベルで宣言型の言語であるため、これにRubyを使用できることは理にかなっています。参照：Gradle、sbt。

実世界の例を挙げましょう。

約15年前、私はCで書かれた大規模システムをUnixからWindowsに移植する作業をしました。これは約300万行のコードでした。スケールのアイデアを得るために、Unixシステム（RS6000）の一部でコンパイルするのに24時間以上かかりました。Windowsは約4時間でシステムをコンパイルできました。

（独自のインタープリター言語で200万行のコードもありましたが、ファイル処理用に設計されていないため、ビルドシステムには使用しないことにしました。また、言語を実装するCコードをコンパイルするビルドシステムが必要でした）

ビルドシステムがシェルスクリプトとメイクファイルの組み合わせで記述されていたとき、これらはWindowsに移植可能ではなかったため、独自のビルドシステムを記述することにしました。

Cを使用することもできましたが、Pythonを使用することにしました。いくつかの理由がありました。（同時にPythonのソースコード管理システムも書き直しました。これはビルドシステムと非常に統合されていたため、チェックインモジュールのオブジェクトファイルは開発者が共有できます。）

• ほとんどのコードは、ファイルの命名規則に基づいて作成されたいくつかの簡単なルール（すべてのプラットフォーム、Windows、VMS、および6バージョンのUnixで数千行のPythonのみ）で構築できます。

• RegExが異なるプラットフォーム上のCシステム間であまり標準ではなかったとき、PythonはRegExを組み込みました。

• いくつかのモジュールにはカスタムビルドステップが必要で、Pythonではクラスファイルを動的にロードできました。フォルダー内に魔法の名前のpythonファイルがあることに基づいて、カスタムクラスを使用してモジュール（lib）を構築することを許可しました。 これがpythonを使用する大きな理由でした。

• Javaを検討しましたが、その時点ではすべてのプラットフォームで出荷されていませんでした。

（ソースコード管理システムのUIでは、すべてのプラットフォームで移植可能なWebブラウザーを使用しました。これは、インターネットに接続できるようになる6か月前でした。X25でブラウザーをダウンロードする必要がありました。）

この質問に対する簡単な答えは、これがビルドツールであるということです。いくつかのソースファイルから最終製品を構築する目的で、他のツールの使用を自動化するツール。製品自体と同じ言語でビルドスクリプトを記述している場合、言語固有のツールの領域に入りますが、これは同じようにビルドツールとは見なされません。

これは疑問を提起します-コンパイラーがmakeのようなツールから慣れ親しんだ種類のビルド自動化を提供しないのはなぜですか？答えは、単にmakeが存在するためです。Unixの「1つのことをして、それをうまくやる」という哲学は、これを提供することはコンパイラの責任ではないことを示唆しています*。そうは言っても、私は個人的に頭痛の種を抱えており、独自の引用符と引用符のない「ネイティブ」ビルドシステムを提供するコンパイラを試してみたいと思っています。

この方法で設計されたコンパイラの例については、C ++の置換を目的とした言語であるJon Blow（まだリリースされていない）Jaiを参照してください。コンパイラーの講演やデモへのリンクはここに集められています。この言語は、コンパイラ内で実行されるバイトコードにコンパイルされます。バイナリへのコンパイルは、バイトコードからアクセス可能な標準ライブラリが提供する関数です。その意図は、言語のネイティブ構文内でビルドの自動化とメタプログラミングの両方を可能にすることです。

_{* MicrosoftのVisual Studioを見ると、反対の哲学の例を見ることができます。:)}

ビルドツールは何よりもまず、「gcc」、「ls」、「awk」、「git」のようなツールです。ツールに入力（ファイル名、パラメーターなど）を入力すると、それに応じていくつかの処理が行われます。

これらのツールはすべて、記述して理解するのに十分簡単な方法で入力を渡すことができます。ビルドツールの特定のケースでは、入力はレシピファイルであり、プロジェクトがソースファイルから完成品にどのように移行するかを記述するファイルです。

レシピが、使用するプロジェクトとコンパイラを含むフォルダーを渡すのと同じくらい簡単な場合、宣言的な「言語」で十分です。レシピがますます複雑になり、ロジックが増えると、宣言型言語で処理するのが面倒になり、より汎用的な言語が使用されます。

ビルドレシピの作成に使用される言語と製品コードの作成に使用される言語は、目的と要件が異なるだけであるため、関連性がないことは明らかです。ビルドツールが書かれている言語とビルドレシピが書かれているべき「言語」の間にも関係はありません。常に仕事に最適なツールを使用してください！