typesafe社が(これ書いている2014-02-23現在) closed sourceで開発してるソフトウェアを勝手に紹介する謎エントリです。
追記: 2014-09-22にオープンソースになったようです！
https://github.com/typesafehub/dbuild
現状ソースはclosedだけれど、以下のサイトでドキュメントは公開されてます。また、jarがあるリポジトリもpublicです。なので、ソースがclosedなだけで、使おうと思えば誰でも使えます
http://typesafehub.github.io/distributed-build
http://repo.typesafe.com/typesafe/temp-distributed-build-snapshots/com.typesafe.dbuild
おもにScala2.11の開発において、バグの早期発見のなどのために役立てているみたいです。開発始まって、使われ始めたのもたぶんここ一年くらいだと思います。その設定ファイルも公開されてます。jsonっぽい形式です。*1
https://github.com/typesafehub/community-builds
scala-internalのメーリングリスト読んでると、けっこう頻繁にでてきます。なんでclosedなソフトウェアの解説書いているかというと、twitterでScala開発者の人がtweetしてたり
Current status: more than 900 thousands lines of #scala code are tested against #scala master. URL #towardsScala211
積極的に宣伝していないとはいえ、全く隠す感じではないし、ソース以外のバイナリやドキュメントはpublicだし、(全く勝手な予想ですが)ソースの公開も時間の問題だと思うからです。
さて、そもそもどんなソフトウェアなのか？というと
「並列に、複数のプロジェクトをまとめてビルドする」
ためのソフトウェアです。
「Scala2.11の開発において、バグの早期発見」
と書きましたが、もう少し具体的にいうと
- ScalaのSNAPSHOTをビルド
- その後 https://github.com/typesafehub/community-builds で設定されている主要なScalaのライブラリを、そのSNAPSHOTのScalaでビルド
- それらはもちろん依存関係があるわけだが、独自に依存グラフを解析する機能とかもあるみたい
- たとえば、community-buildsの設定ファイルには、scalazとspecs2両方書いてある
- specs2はscalazに依存してるので、scalazをビルドしてからspecs2をビルドする
- sbtのマルチプロジェクトになっている場合に、特定のプロジェクトのみをビルドする、テストを実行するかしないか？などの、様々な細かい設定ができるらしい
- おそらく、それぞれのプロジェクトをビルドするためのsbtのversion自体も独自に変更できるみたい？
そして、その「主要なライブラリをSNAPSHOTのScalaでビルドする」というのが、jenkinsで自動化されているようです。
https://jenkins-dbuild.typesafe.com:8499/
また、そのビルドの結果によってなにをしているのかというと
- 意図せずソース互換が崩れてしまった場合(つまりScala本体側のバグが見つかった場合)は、早期にバグ発見して直せるというメリットがある
- ソース互換が崩れたとしても、Scala2.11のSNAPSHOTの変更のほうが正しく、クロスビルドするためにライブラリ側のコードを修正するべき場合は、Scala開発者の人自らライブラリにpull reqを送る
ということが行われています。Scalaz始め、いくつかそういった「Scala開発者の人が自らpull reqする」というのを個人的に観測しています。たとえばこの前書いたこれ
SI-7475 アップキャストするとコンパイル通るようになるのが気持ち悪い
を最初に知ったのも、Scala開発者の人が、scalazにpull reqを送っていたからです。また、internalのMLでも
「dbuildでこの件(SI-7475)に関して、ソース互換崩れるライブラリが見つかったよ(akkaとscalaz)」
というような話題がでてたりします。
https://groups.google.com/d/topic/scala-internals/h8ztMqw-3Xg/discussion
https://github.com/akka/akka/pull/2006
と、まあ、Scala2.11の開発では、Scala2.10のときにはやっていなかった面白い試みがされているわけです。
また、このdbuildというソフトウェアは、Scala本体の開発者が使うだけでなく、
「新しいScalaのversionに対応したバイナリがpublishされてない」
ライブラリに対して
「ユーザーがソースからビルドする」
のに使えるのではないか？と思うのですが、どうなるんでしょうね。
たまに
という話の流れで
「毎回ユーザー側で、すべてのライブラリをソースコードからビルドすればいいじゃん！」
という案がでることがあります。
で、それは確かに不可能ではないのですが、うまくいくか微妙だし、自分が知る限りScalaにおいて誰もその方法をあまり真面目に試した人は見たことありません。
しかし、
dbuildはある意味それをすでに実現できている
気がします。まぁソースはclosedだし、実際自分はまだ試してないのでどのくらいその辺り柔軟性があるのかわかりませんが。
はやくopen sourceにならないかなぁ・・・。migration managerというtypesafeが以前しばらくclosedで作っていたソフトも、結構後になって公開された経緯があります。
たぶんこのdbuildも、それほど誰もが使うようなソフトウェアではなく、わりと特殊な用途でまだ完成度が高くなく、公開しても面倒が増える割にはそこまでメリットがない？という判断なのでしょうかね。
