Come determinare quando giocare! 2 deve ricompilare tutti i file?

Question

Quando modifica un file scala nel mio Play 2 app, a volte solo alcuni file vengono ricompilati, ma spesso l'intero codebase deve essere ricompilato:

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

contro

[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 

Tuttavia non vedo schema discernibile per quando è necessaria una ricompilazione completa. Se aggiungo qualcosa di spazio a un modello o a una classe controller, è possibile compilare solo quel file, ma facendo lo stesso con un file comparabile verrà avviata una ricompilazione.

Vorrei amore per avere il maggior numero di ricariche di essere più vicino a 1s, perché attualmente sto aspettando una ricompilazione completa il più delle volte. Mi piacerebbe refactoring il mio codice per rendere più veloce per ricaricare le aree su cui sto lavorando, ma non so cosa potrei fare per ottenerlo. Le ricompense frequenti sono normali per una tipica app Play 2 o c'è qualcosa di anomalo nei miei?

Answer 1

In generale, se si modifica "l'API di origine" di un file, le dipendenze di tale file vengono ricompilate. L'API di origine è costituita dalle firme di metodi e tipi non privati. Quindi, se si dispone di un file da cui tutto dipende, le modifiche alle firme in quel file potrebbero causare un sacco di ricompilazione. Inoltre, quando l'API di un antenato cambia, tutti i discendenti devono essere ricompilati.

È possibile ottenere alcune informazioni aggiuntive da last compile, ad esempio ciò che ha attivato la ricompilazione di altri file. (In una build a più moduli, last <project-name>/compile)

Se aggiungendo spazi bianchi non significativi si ricompilano altri file, è sempre un errore, spesso in scalac stesso. Un esempio di tale bug è SI-7361 (non che sia utile a nessuno, oltre agli sviluppatori di compilatori!) Che è stato risolto in sbt here. Affinché questi siano corretti, abbiamo bisogno di un caso di test riproducibile. (Dato lo sforzo spesso coinvolto in questo, potresti aspettare 0.12.4 o 0.13.0 per vedere se quelli risolvono il tuo problema.)

0.13.0 ha alcuni miglioramenti che si spera possano ridurre ciò che viene invalidato quando le API cambiano.

Answer 2

Penso che tu stia per l'approccio leggermente sbagliato qui. Poiché non esiste alcun modo per determinare con successo quali modifiche causeranno la ricompilazione completa, tale percorso non porta da nessuna parte.

Ai fini dell'apprendimento, forse è utile essere a conoscenza degli interni del compilatore in misura maggiore, ma dal punto di vista della produttività c'è una scelta molto migliore disponibile, e questo è jRebel, che ha distribuito licenze Scala gratuite per anni.

JRebel

Da here, è possibile ottenere una licenza gratuita Scala in pochi minuti. Poi vai avanti e aggiungi questo alla configurazione di sbt. Deve andare direttamente nel file sbt.

Linux/Mac

java -noverify -javaagent:/opt/zt/jrebel/jrebel.jar \ 
-Xmx1024M -Xss2M -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled -jar \ 
`dirname $0`/sbt-launch-0.12.jar "$@" 

di Windows

set SCRIPT_DIR=%~dp0 
java -noverify -javaagent:c:/opt/zt/jrebel/jrebel.jar \ 
-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m -Xmx1024M -Xss2M \ 
-jar "%SCRIPT_DIR%\sbt-launch-0.12.jar" %* 

In questa fase, se hai fatto tutto per bene, quando si ri-avviare la console SBT si vedrà che jRebel Agent è stato avviato e trarrai vantaggio dalla ridistribuzione in tempo reale delle tue modifiche. Quando nel tuo IDE hai Save, JRebel ricaricherà solo le modifiche che hai apportato.