9

Play 2 アプリで scala ファイルを編集すると、いくつかのファイルのみが再コンパイルされることがありますが、多くの場合、コードベース全体を再コンパイルする必要があります。

[info] Compiling 1 Scala source to /home/michael/code/superglot/target/scala-2.10/classes...
[success] Compiled in 1s

対

[info] Compiling 2 Scala sources to /home/michael/code/superglot/target/scala-2.10/classes...
[info] Compiling 52 Scala sources and 1 Java source to /home/michael/code/superglot/target/scala-2.10/classes...
[success] Compiled in 13s

ただし、完全な再コンパイルが必要な場合の識別可能なパターンは見当たりません。モデルまたはコントローラー クラスにホワイトスペースを追加すると、そのファイルのみがコンパイルされる可能性がありますが、同等のファイルに同じことを行うと、再コンパイルがトリガーされます。

現在、完全な再コンパイルを頻繁に待っているため、リロードの多くを 1 秒に近づけたいと思っています。喜んでコードをリファクタリングして、作業中の領域のリロードを高速化しますが、それを達成するために何ができるかさえわかりません。典型的な Play 2 アプリでは、頻繁に再コンパイルするのは正常ですか?それとも、私のアプリに何か異常があるのでしょうか?

4

2 に答える 2

7

一般に、ファイルの「ソース API」を変更すると、そのファイルの依存関係が再コンパイルされます。ソース API は、プライベートではないメソッドと型のシグネチャで構成されています。そのため、すべてが依存するファイルがある場合、そのファイルの署名を変更すると、多くの再コンパイルが発生する可能性があります。また、祖先の API が変更された場合、すべての子孫を再コンパイルする必要があります。

last compile他のファイルが再コンパイルされるきっかけとなったものなど、いくつかの追加情報を から取得できます。(マルチモジュール ビルドでは、last <project-name>/compile) 次のことができます。

意味のない空白を追加すると他のファイルが再コンパイルされる場合、それは常にバグであり、多くの場合 scalac 自体にあります。そのようなバグの例はSI-7361 (コンパイラ開発者以外の誰にとっても役に立つというわけではありません!) で、sbt here で回避されました。これらを修正するには、再現可能なテスト ケースが必要です。(これには多くの労力が伴うため、0.12.4 または 0.13.0 で問題が解決するかどうかを確認するまで待つこともできます。)

0.13.0 には、API が変更されたときに無効になるものを減らすことが期待されるいくつかの改善があります。

于 2013-05-11T01:16:16.290 に答える