Don't include resources into compileClasspath. #1811
Conversation
lefou
added
the
compat-breaker
|
This looks ok so far, but this need to wait until the next major version (probably To get CI green, some tests need to be adapted. |
We have no clear rule when to start development on next major. Until now, we just bumped the version when needed. So that might be also the case for this PR. But as we now take compatibility serious, we should avoid too many major bumps in a short time to remove stress from downstream projects like external Mill plugins. |
|
This is the error in CI: You need to reflect the changed resource directory name in the |
|
@lefou thanks will fix that. I saw a lot of ci failures and didn't still had enough time to find which of them were caused by my change. thanks for pointing out. any particular suite you recommend me to run ? |
|
As you touch |
Instead we now have a compileResources that is part of compileClasspath.
|
We finally merged it. Thanks @vic for this contribution and your patience! |
…ring compilation (#2425) Instead of compiling the buildinfo values into the source code, we only compile the buildinfo keys into the source code and store the buildinfo values in the resources, to be loaded at runtime. This greatly reduces the amount of time spent compiling things when buildinfo changes. In this repo, some rough tests indicate that it makes the second `-i installLocal` after a one-line change in the `LICENSE` file drop from 50s to 14s of runtime `mill-profile.json` Before: [mill-profile.txt](https://github.com/com-lihaoyi/mill/files/11177836/mill-profile.txt) `mill-profile.json` After: [mill-profile.txt](https://github.com/com-lihaoyi/mill/files/11177798/mill-profile.txt) Notes: 1. To really benefit from this, I had to make `compileClasspath` depend only on upstream module's `compileClasspath()`/`compile().classes`, so it doesn't end up depending on their runtime `resources()` and forcing unnecessary recompiles when the buildinfo resources change. This is probably a change we want to do anyway, given the direction set by #1811 2. I consolidated the BuildInfo implementation with `contrib/buildinfo/`. 3. Extended `contrib/buildinfo/` to support Java modules, which we dogfood in `main.client`. 4. The old behavior of statically compiling the values into the binary is still available under `def buildInfoStaticCompiled = true`, for anyone who needs it. That includes anyone using `BuildInfo` in Scala.js, which doesn't support JVM resources by default 5. For now, I copy-pasted the implementation into the root `build.sc` file, and updated `mill-bootstrap.patch` to remove it and make use of the `mill-contrib` version. When we re-bootstrap Mill on latest main, we can remove the copy-pasta 6. `contrib/buildinfo/` should be mostly source compatible with the previous implementation, except that I made `buildInfoPackageName` a required field to encourage the best practice of not putting code in the empty package
Instead we now have a compileResources that is part of compileClasspath.
Fixes #1807