この記事は、 DMD 2.079.0 Released – The D Blog を自分用に翻訳したものを 許可を得て 公開するものである。
ソース中にコメントの形で原文を残している。 誤字や誤訳などを見つけたら今すぐ Pull requestだ!
D言語財団はDプログラミング言語のリファレンスコンパイラ、DMDのバージョン2.079.0をアナウンスします。 この最新版は複数のパッケージでダウンロードできます。 チェンジログでこのリリースの78人のコントリビュータによる 変更とバグフィックスを見ることができます。
リリースの中のどの改善をこのブログで取り上げるか選ぶ作業はいつだって簡単ではありません。 誰かにとって重要なことが他の誰かにとっては関心のないことだったりします。 今回、特にどれを選ぶか悩みました。 しかし、Dプログラミング言語の、特に初心者のエクスペリエンスに大きな影響をもたらすポテンシャルを持つ、特に目立つ2つを紹介します。
Visual Studioが不要に
チェンジログでは小さな1エントリでしかありませんが、これはWindowsにおけるDでのプログラミングにとって大きな変更です。
64ビット実行ファイルをリンクするのにもはやMicrosoftツールチェインは必要ありません。
前回のリリース1
ではコンパイラの設定を不要にすることで作業が簡単になりました。
コマンドラインに-m32mscoffまたは-m64が渡された場合、Visual StudioやMicrosoft Build Toolsがインストールされていないか検索します。
このリリースではそこからさらに改善されました。
WindowsのDMDはVC 2010 C ランタイムのラッパライブラリであるMinGWからビルドされたプラットフォームライブラリとセットで配布されるようになりました
(チェンジログはインストーラについてしか言及していませんが、zipパッケージにもバンドルされています)。
-m32mscoffや-m64フラグが与えられ、コンパイラがWindows SDKのインストール
(最新版のVisual Studioでは一緒にインストールされます。古いバージョンでは別にインストールが必要です)
を検出できなかったとき、これらのライブラリにフォールバックします。
更に、コンパイラはlld、LLVMのリンカも合わせて公開されます。
MSのリンカが見つからなければ、かわりにこれが使われます(ただし、現在はこのリンカの使用は実験的なものです)。
というわけで、64ビットと32ビット COFFの出力はOMFの出力(-m32、デフォルトです)を持つためWindowsにおいて「箱から出してすぐ使える」ようになりました。
これによってWindowsにおいて、めんどくさいVisual Studioのインストールと設定が必要なCやC++のバックグラウンド無しでDを始めるのが簡単になりました。
自動コンパイルされるインポート
Dの初心者、特にJavaをバックグラウンドに持つ人におけるもう一つの変化が、インポートの扱い方です。 由緒正しい‘Hello World’を例に考えてみましょう:
import std.stdio;
void main() {
writeln("Hello, World!");
}
インポートしたモジュールが自動的にコンパイルされる言語から初めてDに来た人は、ここで起きていることを前提として受け入れます。
もちろん、それは間違っています。
std.stdioモジュールはPhobos、Dの標準ライブラリの一部であり、プリコンパイルされたライブラリとしてコンパイラと一緒に配布されるものです。
実行ファイルや共有ライブラリをコンパイルするとき、コンパイラはそれをリンカに生成されたオブジェクトファイルとともに渡します。
新人が驚くのは以下のように複数のファイルをコンパイルしようとしたときです:
// hellolib.d
module hellolib;
import std.stdio;
void sayHello() {
writeln("Hello!");
}
// hello.d
import hellolib;
void main() {
sayHello();
}
一般的な間違いとして以下のようなことが行われ、結果としてリンカはsayHelloシンボルの不足をエラーとして報告します:
dmd hello.d
Dコンパイラはインポートされたモジュールについて考えません。 コマンドラインで渡されたソースファイルのみがコンパイルされます。 つまり上のものを正しくコンパイルするにはこのようにします:
dmd hello.d hellolib.d
import文がコンパイラに伝えるのはシンボルが現在のコンパイルユニットから見えてアクセスできるということであり、ソースファイルをコンパイルしなければならないということは伝えません。
言い換えると、コンパイル中、コンパイラはインポートされたモジュールがすでにコンパイルされたものか、コンパイルしてほしいものなのかについて関知しないということです。
ユーザーは明示的にコンパイルしてほしいソースモジュールか、プリコンパイルされたオブジェクトまたはライブラリファイルを渡さなければなりません。
インポートされたモジュールのコンパイルのサポートは不可能ではありません。
それはリンクの段階の存在によって回避不能な問題を引き起こします。
たとえば、libFoo静的ライブラリをリンクするため、libFooからインポートしたモジュールをコンパイルしたくないという場合です。
それはビルドツールの領域であり、それはビルドツールに任せるというのが哲学です。
DMD 2.079.0は流れを一変させます。 上の例は以下のようにコンパイル・リンクできます:
dmd -i hello.d
-iスイッチはインポートされたモジュールをコマンドラインに渡されたかのように扱うようコンパイラに指示します。
これはモジュールまたはパッケージ名を渡すことで指定のモジュールやパッケージに制限でき、同様にダッシュを先頭につけることで除外できます:
dmd -i=foo -i=-foo.bar main.d
この場合、完全修飾名がfooで始まるモジュールが、foo.barで始まるものを除きコンパイルされます。
デフォルトでは、-iはインポートされたモジュールのうちPhobosとDRuntime以外すべてをコンパイルします。
つまり:
-i=-core -i=-std -i=-etc -i=-object
ビルドツールを完全に置き換えるものではありませんが、クイックテストや複雑な設定の必要ないプログラムが簡単にコンパイルできるようになります。
#dbugfix キャンペーン
関連事項として、先月私は#dbugfix キャンペーンをアナウンスしました。 簡単に言うと、修正してほしいD Bugzilla issueがあるなら、issue番号を**#dbugfixをつけてツイートするか、 Twitterアカウントを持っていない、またはissueについて議論したい場合は総合フォーラムにissue番号と#dbugfix**をタイトルに入れて投稿する、というものです。 コアチームはその後のコンパイラのリリースで、それらのissueのうち少なくとも2つを修正するためにコミットします。
通常、私はメジャーコンパイラリリースの2ヶ月前からデータを集めます。 最初は3ヶ月なれる期間を用意していました。 私はそれは流行るのにはおそすぎると予想しており、どうやら正しかったようです。 アナウンスの数日後少しissueがツイート・投稿され、その後静かになりました。 これまでのところ受け取っているものです:
DMD 2.080.0はDConf 2018が始まるころに予定されています。 考慮する締切日は2.080.0ベータがアナウンスされる頃です。 これによってバグ修正者がどれに取り掛かるか考える時間ができます。 私は集計と選ばれたissueをDMDのリリースのアナウンスメントに含め、バグ修正者は修正の実装に取り掛かり以降のリリース(できれば2.081.0)でPRをマージします。 2.080.0がリリースされると、#dbugfix issueをまた次のサイクルのために収集します。
上のリストにないけれど修正してほしいissueがあれば、#dbugfixに投稿してください! また、#dbugfixissueをリツイートしたり、フォーラムで**+1**するのもいいでしょう。 それらは考慮されます。 そして、issue番号を含めるのも忘れないでください。 でないとカウントされません!