search

typelevel / spire

Powerful new number types and numeric abstractions for Scala.
http://typelevel.org/spire/
MIT License
1.76k stars 243 forks source link

Systematic recompilations of some sources #156

Closed luc-j-bourhis closed 6 years ago

luc-j-bourhis commented 11 years ago

Every time core/test or core/compile is fired, sbt reports that 3 Scala sources from core/target/scala-2.10/classes/... and then 1 class source from the same place (the … is what sbt prints out: I don't know the exact path) are compiled.

d_m said on irc that he thinks this is related to codegen, i.e. some files are always "dirty". This is annoying on a slow machine as those recompilations can take a few seconds.

tixxit commented 11 years ago

Yes. This is a very annoying problem. Part of it is the code-gen (ie. the tuple instances). I think they're always recompiled (may be wrong). However, it is also very easy to hit situations where all 100+ files are recompiled, which takes 2-3 minutes on my computer. It has gotten slightly better, but this is still a very annoying problem. Mark Harrah has said that if we provide a test case (ie. "change this line in spire, watch 100+ files recompile"), that he'd try to fix it.

On Wed, Sep 18, 2013 at 9:33 AM, Luc J. Bourhis notifications@github.comwrote:

Every time core/test or core/compile is fired, sbt reports that 3 Scala sources from core/target/scala-2.10/classes/... and then 1 class source from the same place (the … is what sbt prints out: I don't know the exact path) are compiled.

d_m said on irc that he thinks this is related to codeine, i.e. some files are always "dirty". This is annoying on a slow machine as those recompilations can take a few seconds.

— Reply to this email directly or view it on GitHubhttps://github.com/non/spire/issues/156 .

luc-j-bourhis commented 10 years ago

So part of it is a bug in sbt then. The 100+ files recompilation, certainly (I haven't encountered that yet). But the recompilation triggered by the code-gen of tuples? Does it need sbt to be fixed too or is there a possible workaround?

non commented 10 years ago

We've figured out that this is related to quasiquotes, which are unfortuantely really important for cfor, cforRange and so on.

As a work-around you can define non-macro definitions for those, comment out the macros, and have things go faster.

denisrosset commented 6 years ago

Closing for now. We are modularizing Spire, which should help a bit.