-
|
Compilation of my project is dependent on some env vars (there's a Scala macro that checks env vars and changes generated code accordingly). Howerver, currently if env var is changed, already compiled source files are not recompiled - since compiler assumes that nothing changed. Is there a way to force Mill to recompile all files if task dependency changed? I tried the following: However, |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
Not really, since the compiler isn't supposed to forward env-vars to plugins and macros, or however you are using them. Even, if you can convince the compiler to re-run, but do not clean the previous run, you still risk an inconsistent build due to incremental compilation support in Zinc (used for Java and Scala) or Kotlinc, which will very likely not detect the env changes as invalidation reason. Instead, you should make your environent dependencies explicit. One way I can think of is converting them into compile-time resources. E.g. you could generate a def myEnvInput = Task.Input {
Task.env.getOrElse("X42", "")
}
override def compileResources = Task {
os.write(Task.dest / env.properties", s"compile.X42=${myEnvInput()}")
super.compileResources() ++ Seq(PathRef(Task.dest))
} |
Beta Was this translation helpful? Give feedback.
-
|
Found an easy way to solve my issue - just inject the env vars into a generated source file. This nicely handles all problems through standard cache invalidation mechanisms - macros get invalidated because their dependency changed, macro-generated code gets invalidated because macro changed, so all affected items are cleanly recompiled (as a bonus - this works nicely with incremental compilation, source files that don't use these macros are not recompiled). This approach can probably be used for any other situation where compilation is dependent on env vars (or other inputs). Full example: |
Beta Was this translation helpful? Give feedback.
What did work was to dump the env vars into the same file as macros definitions - this finally ensures that Macros.scala is recompiled (previously it didn't recompile because outputs would be the same - still the same references to MacrosEnv).
So the final example: