ジェーンストリートテックブログ – OCAMLのためのより良いビルドシステムを誤って構築する方法

「ビルドシステム」は、開発者のツールボックスで最も重要なツールの1つです。大まかに、コンパイラに呼び出し、テストスイートのセットアップと実行など、さまざまなソースファイルから実行可能なプログラムを作成する方法を見つけます。あなたは毎日それとやり取りするので、何よりもそれは 速い – しかし、それも柔軟でなければなりません。

2012年頃、私たちはOCAMLの標準ビルドシステムの1つであるOmakeに不満を抱いていました。この新しいシステムJengaと呼びました。それは私たちにとって非常にうまくいきました、そして、私たちは、より広いコミュニティがそれが役に立つと思うかもしれないと思いました。そこで、Jengaをリリースすることにしました。他の人がそれを試したとき、彼らはそれを好み、おそらくそれに貢献することさえ望んでいました。また、リリースすると、コードをオープンしやすくなります。

ハ！実際に起こったのは、誰も本当にジェンガを使いたくなかったということです。一つには、Windowsで動作しませんでした。しかし、ジェンガを採用することは、OCAMLを建設する「ジェーンストリートウェイ」全体を採用するために効果的でした。私たちがそれを受け入れたいと思っていた人々によるジェンガの採用は、私たちが実際に決めたほど十分に弱かった そして– オープンソース。そして、私たちは以前と同じ場所に戻りました。

2016年までに私たちはこれを十分に持っていて、JBuilderと呼ばれるシンプルなクロスプラットフォームツールを作成することにしました。ビルドイン
ocamlbuild、その後、OCAMLプロジェクトを構築するための新たな基準。

JBuilderは理解しました jbuild Jengaが構成をビルドするために使用し、必要なすべてのコンパイルコマンドをトポロジ順に実行するファイル。それは通常の意味でのビルドシステムではありませんでした。それは、すべてのコマンドを毎回再実行するだけです（入力が変更されたコマンドを再実行するだけではありません）。

JBuilderが人気を博し、「砂丘」になります

その後、奇妙なことが起こりました。人々 愛されています jbuilder。彼らはそれを使用して、私たちのパッケージだけでなく、自分のパッケージも構築し始めました。最初はこれを本当に理解していませんでした。結局のところ、JBuilderは実際のビルドシステムではありませんでした。それはちょうど少し互換性のあるシムになることを意図していました。

最終的に、私たちが気づいたのは、魅力的な機能が速度であるということでした。 JBuilderは他のオプションよりもはるかに速く、OcamlBuildよりも5倍速いプロジェクトをコンパイルすることが判明しました。それに加えて、システムがポータブルでハッキングしやすいシステムは、早期採用者や貢献者にとって重要なことでした。

したがって、協力して OCAMLラボ
（そして今日、 TARESで）、私たちはJBuilderをより多くの実際のビルドシステムにすることに取り組み始め、より広いオープンソースの世界にとって有用なツールになるために必要な機能をさらに追加しました。

そして、別の問題に遭遇しました。名前。

すでに「ボーランドのジャワ」が「」と呼ばれていたことが判明しました。jbuilder。」このシステムは長い間廃止され、著作権の現在の所有者を見つけて、名前を使って私たちに気にするかどうかを尋ねるのに苦労しました。しかし、サイコロはありません。

そこで、新しい名前を選ぶことにしました。私たちはしました コミュニティアウトリーチの少し、「砂丘」が勝利名として浮上しました。

それまでの間、デューンの人気は爆発しました。人々は本当にそれを本格的に使用し始めました、そして、私たちはややばかげた、自傷行為の状況に自分自身を見つけました。私たちは今、維持とサポートするための2つのフルビルドシステムを持っていました。

ジェンガ対デューン

Duneがより優れたシステムであることが明らかになりました。再考された設計、ほとんどの人のビルドでより速く、採用が広く、APIとユーザーエクスペリエンスが向上し、「Jane StreetをDuneに移動するのはいつですか？」ツールの出所を考えると、これはばかげた質問のように感じられましたが、まあ、それは私たちが終わったところです。

Build Systemsチームは、成長しているコードベースに追いつくだけで十分に取り組む必要があるため、答えは必然的に「来年」でした。 （2016年、Duneが開始されたとき、4mのOCAMLコードがありました。今日は65mと5mのPythonがあります。）Duneへの移行は、ミッションに完全に着手することはありませんでした。しかし、そうではありませんでした それで
私たちが、それが次の6か月から12か月で起こる可能性があると、私たちが願望的に推定することを妨げるのは困難です。

私たちがついにバンドエイドをリッピングすることを決めたのは昨年だけでした。私たちはビルドシステムチームを5人のフルタイムエンジニアに成長させたので、私たちは最終的に私たちが長い間恐れていたこのモンスターに取り組む力を持っていると感じました。

デューンはジェン・ストリート内のジェンガを包含します

最初はあまり感謝していなかった大規模な作業の1つは、巨大なコードベースにデューンスケールを作ることでした。 Duneは非常に高速で外部的でしたが、ほとんどのユーザーがJane Streetの70mラインリポジトリと比較して比較的小さなものを構築したためです。

そして、ジェンガもじっと立っていませんでした。 10年以上にわたって、コードベースの成長に対処するための実装を改善しました。これにより、スケールに対して非常によく最適化されたシステムが生成され、モノレポの要件に慎重に調整されました。さて、その優れた最適化作業の多くは砂丘に翻訳する必要がありました。

もっとありふれた問題がありました。ビルドシステムは、特に3つの異なる編集者（VIM、EMACS、およびVSCODE）から、さまざまなワークフローによって呼び出されます。それぞれが悲しいことに、ジェンガとの独自のカスタム統合を持っていて、砂丘を1つずつ使用するために移行する必要がありました。

しかし、1年以上の集中的な作業の後、私たちはついに完了しました。私たちのコードベースはDuneによって構築されました。スイッチの時点で、デューンのパフォーマンスはジェンガのパフォーマンスよりも優れているか、それ以上のパフォーマンスがあり、場合によってははるかに優れていました。特に、ほとんどのビルド作業がすでにキャッシュ中にあるビルド（これは驚くほど一般的なケースです！）は2〜3倍速くなりました。

Duneのパフォーマンスを向上させるために私たちがしたことの多くは、オープンソースになり、一部はすでに持っています。私たちは、砂丘のジェーンストリートフォークと外部砂丘の2つのビルドシステムを再び装着しないことを切望しているので、私たちはできる限り変化を上流にすることに多くの思考とエネルギーをかけています。

デューンは、新しいことをするための非常に良い基盤です。その一部は、Duneのコードベースがよりシンプルで作業しやすいためです。 1つのシステムに焦点を合わせることができるからです。しかし、分散ビルド、浅いビルドなどの機能（ 「バイトなしでビルド」）、そしてビルドグラフ自体のキャッシュされた負荷は、これまで以上に範囲に近づいています。

今後のエキサイティングなことは、単一のシステムがあり、それを改善する速度が上がっていることです。チームはまた、ニューヨーク、ロンドン、シンガポールの12人のフルタイムエンジニアに成長しました。つまり、現在24時間デューンに取り組んでいます。

それは長く、時には蛇行する道であり、確かに私たちが計画した方法を展開していません。しかし、最終結果は、ジェーンストリートの壁の内外の両方で、OCAMLのビルドシステムストーリーに適していると考えています。