Avoiding some modules/platforms compilation in BSP

[PapyChacal]

Hello, we are using Mill in a Scala project that is starting to grow in size. (A quick huge thanks for Mill in general, it does wonders overall!)

We want our project to compile as a GraalVM Native Image, as well as against Scala Native. So I followed the example I could find, that is fansi's build definition: https://mill-build.org/mill/scalalib/build-examples.html#_fansi. So I defined .jvm, .native and .graal submodules in my build definition, with the corresponding configurations.

It works great for what we wanted to achieve! We have one big pain regarding this, though; at least with VSCode's Metals extension, this leads Metals to recompile all those targets every time, so the IDE is triggering fully-optimised binary rebuilds constantly. We only want Scala language support from this, though, and as far as I understand, this only requires the typical JVM compilation. (I'm also curious if someone feels like I'm missing something else on that assumption)

I tried cloning and checking things on https://github.com/com-lihaoyi/fansi, and it seems it has the same "issue"; it simply induces negligible overhead there, so it isn't a problem, but it could be used as a MWE.

So my main question is, are there any known ways to avoid such optional targets to constantly recompile as part of the BSP? Or any related discussions I missed?

I would even appreciate a completely ad-hoc workaround for now, as this is becoming a pragmatic issue on our end; some contributors just disabled language support, as this completely clogs lower-end machines.

Thanks!

[lefou]

This looks related to

• Feature Request: bspEnabled equivalent #5298

which I already have on my working list. But your question/request just increased the priority. ;-)

[PapyChacal]

Oh, sorry I missed that, and thanks for the answer, it's great to know it’s on the map 😀

[lihaoyi]

This is included in the latest development release 1.0.6-114-ed0e74 containing #6065 from @alexarchambault