rdmdはimport先を自動解決してくれるのでスクリプト管理が楽になる

はじめに

D言語はスクリプト用途にめっちゃ便利という記事が思ったより好評だったので、他にもこんなところが便利という続編です。要はポエムに軸足置いたゆえに書き損じてたところの補足です。

元記事

複数ファイル分割

rdmd はソースを複数ファイルに分割できます。D言語ならそりゃそうでしょ、と思うかもしれませんが、何が良いかと言えば「実行のために参照先ファイルを指示する必要がない」ということです。

たとえば

sandbox
  start.d
  build.d
  common.d

というファイル構成に対し、start.d -> common.d, build.d -> common.d といった参照があっても rdmd start や rdmd build とするだけで実行できるということです。

もう少し具体的に書くと以下のような感じですね。

common.d

module common;

enum url = "https://github.com";

start.d

import std;
import common; // 同フォルダのcommon.dをimport
void main() {
    writeln("start: " ~ url);
}

build.d

import std;
import common; // 同フォルダのcommon.dをimport
void main() {
    writeln("build: " ~ url);
}

静的コンパイルなのになんだか動的ロードみたいにも見えます。

とまぁこれで複数のコマンドがあっても共通変数などを1か所で管理できるようになり、保守性が大幅に改善されます。
いつものD言語っぽくて良い感じですね。

コンパイラの run スイッチとの違い

前記事への反響として、「rdmd を使わなくても大体 dmd run start.d で済ませちゃう」といった話があり、確かにそれで良い気がする、とその時納得していました。

公開翌日に別件でふとスクリプトをメンテしていたところ、そういえばrdmdはファイル分割できるな、と思って試したらやっぱり動くぞ！ということで本記事を書くに至った次第です。

ここでコンパイラを使う場合、 dmd -run start.d common.d と両方指定してやれば良い気がしますが、試してみるとエラーでした。
エラーの理由は -run の場合はファイルが1つだけという縛りがあるため、2つ目のファイル指定が実行時の引数と解釈されてシンボルが見つからずリンカエラーになるためです。（そういうもの？）

結果、 dmd start.d common.d からの ./start.exe みたいなことになり、これが rdmd start で1コマンドでOK、ということでちょっと楽になります。

なんというか、色々わかってる人が作った感があって良きかな良きかな、という感想です。
何よりコンパイラに同梱されてるのがありがたいんですけどね。