incremental-compiler | 易学教程

When does IntelliJ's Scala incremental compilation happen?

阅读更多关于 When does IntelliJ's Scala incremental compilation happen?

问题 When does IntelliJ's Scala incremental compilation happen? I notice that making changes to a file does not cause the corresponding .class files (in /target) to be updated. When does this happen? 回答1: I think you misunderstand how Scala incremental compilation works. There are 2 different things that might be called "IntelliJ's Scala incremental compilation ": 1) Proper Scala incremental compilation which is more or less a set of typcial strategies applicable for different programming

llvm: strategies to build JIT content incrementally

阅读更多关于 llvm: strategies to build JIT content incrementally

问题 I want my language backend to build functions and types incrementally but don't pollute the main module and context when functions and types fail to build successfully (due to problems with the user input). I ask an earlier question regarding this. One strategy i can see for this would be building everything in temp module and LLVMContext , migrating to main context only after success, but i am not sure if that is possible with the current API. For instance, i wouldn't know know to migrate

Is wildcard import bad in Scala with respect to incremental compilation?

阅读更多关于 Is wildcard import bad in Scala with respect to incremental compilation?

问题 In Scala, is it bad, from the point of view of efficacy and speed of incremental compilers (sbt, sbt in Eclipse, IntelliJ), to use wildcard imports? Does it adversely affect the way these incremental compilers decide what to recompile in case of changes? For instance, if for a new class X , I would only need to import classes A and B (and not C ) from package pack , do I get a penalty for writing this: import pack._ instead of this? import pack.{ A, B } Assuming A and B have no dependency on

How to properly deal with class dependencies to utilize incremental compilation in Java/Android with Gradle?

阅读更多关于 How to properly deal with class dependencies to utilize incremental compilation in Java/Android with Gradle?

问题 I improved our build system and activated incremental builds and compilation as described in this question. To my disappointment, incremental compilation didn't improve build times as much as I expected from reading Gradles blog post. After some investigation, I realized that the issue is that even though I only add a comment to a small class somewhere deep in the app apparently almost the whole codebase is rebuilt. In fact, it doesn't really matter which class I touch, Gradles --debug output

SBT plugin: How to list files output by incremental recompilation

阅读更多关于 SBT plugin: How to list files output by incremental recompilation

问题 I am writing a plugin for SBT that requires a list of the class files generated by the last run of the Scala compiler. This list of class files is then passed into a program that performs some bytecode transformations. Since this transformation process can be slow, I only want the class files written by the last run of the Scala compiler (i.e. those that there modified), not all class files in the output directory. How can I obtain a list of the files last generated by the compile task? 回答1:

Can standard Sun javac do incremental compiling?

阅读更多关于 Can standard Sun javac do incremental compiling?

问题 Recently I started to use Eclipse's java compiler, because it is significantly faster than standard javac. I was told that it's faster because it performs incremental compiling. But I'm still a bit unsure about this since I can't find any authoritative documentation about both - eclispse's and sun's - compilers "incremental feature". Is it true that Sun's compiler always compiles every source file and Eclipse's compiler compile only changed files and those that are affected by such a change?

How to avoid a class dependency monolith using Intents in Android?

阅读更多关于 How to avoid a class dependency monolith using Intents in Android?

问题 As I describe in this question I can not utilize Gradle's incremental compilation properly, as almost our whole codebase is dependent on each other. This causes almost 500 classes to compile all the time. I found out that many of the class dependencies are caused by the use of explicit Intents like such: Intent intent = new Intent(context, NewActivity.class); This creates a class dependency from the current class to NewActivity . Connecting activities in this way quickly form a class

what is the right abstraction for compilation unit in LLVM?

阅读更多关于 what is the right abstraction for compilation unit in LLVM?

问题 in LLVM we have the LLVMContext , which is the unit of storage, and we have the llvm::Module , which is where new symbols (functions and types) are built. my question is; what is the right llvm abstraction to use for compilation units? is the Module ? or is this actually meant for a bigger scope, i.e: a shared library target It seems to me that a compilation unit must satisfy an all-or-nothing result; either it compiles all its content without errors, or either there are errors and it needs

Is wildcard import bad in Scala with respect to incremental compilation?

阅读更多关于 Is wildcard import bad in Scala with respect to incremental compilation?

In Scala, is it bad, from the point of view of efficacy and speed of incremental compilers (sbt, sbt in Eclipse, IntelliJ), to use wildcard imports? Does it adversely affect the way these incremental compilers decide what to recompile in case of changes? For instance, if for a new class X , I would only need to import classes A and B (and not C ) from package pack , do I get a penalty for writing this: import pack._ instead of this? import pack.{ A, B } Assuming A and B have no dependency on C , would X be recompiled with the wildcard import and not with the more specific import when C changes

How to properly deal with class dependencies to utilize incremental compilation in Java/Android with Gradle?

阅读更多关于 How to properly deal with class dependencies to utilize incremental compilation in Java/Android with Gradle?

I improved our build system and activated incremental builds and compilation as described in this question. To my disappointment, incremental compilation didn't improve build times as much as I expected from reading Gradles blog post . After some investigation, I realized that the issue is that even though I only add a comment to a small class somewhere deep in the app apparently almost the whole codebase is rebuilt. In fact, it doesn't really matter which class I touch, Gradles --debug output reveals that it basically always recompiles 476 classes. Incremental compilation of 476 classes