Just for the future - associates is in some way similar to go's embed https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/rules.md#go_binary-embed

Is the Kotlin extension spec here? And is that pretty much final?

Also - what exactly is in the associates field and how does it differ from BuildTarget#dependencies. The Go embed link seems to suggest it's packaging related - so is this for some kind of fat jar setup? And how would a BSP client use this information - I would have thought that would all be hidden in the build tool/server and the client wouldn't care.

@abrams27

associates means that the targets will be compiled together in one "module" so you can use symbols with internal visibility (https://bazelbuild.github.io/rules_kotlin/kotlin#kt_jvm_library) on the client side this info is required (at least in intellij) since we map 1-1 build targets so it's required to handle internal visibility properly

@abrams27 Ah thanks. I don't know Kotlin and didn't realise internal was a visibility keyword.

Is the Kotlin extension spec here? And is that pretty much final?

I wouldnt say that this impl is final, it works for us, but possibly it should be adjusted to feel more consistent with other langs, so prob we can add some endpoints instead of putting everything into data field of the build target

This is interesting. How do you provide associates to the Kotlin compiler? I maintain a Kotlin plugin for Mill, and I'm not aware of such compiler option.

we dont pass it directly to the complier, on the server side bazel takes care of that, on the client side we pass it to the lang support plugin which has a field called additionalVisibleModuleNames

anyway on slack someone mentioned -Xfriend-paths=<friend-module-output> as a compiler option suitable for it

Yeah, I guess I'm actually more interested in the server side then. It looks a bit strange to me to control the friendship between modules via a keyword from the one side, but via a compiler setting from the other.

From it's documentation (https://kotlinlang.org/docs/visibility-modifiers.html#modules) it looks to me, internal is supposed to be used only in the same module (same BSP build target), so they result to be compiled together.

yes but there are cases when it's a "fictional" thing - for example library and test, in bazel it's impossible to compile them together, but the test in the same package should be able to see the symbols, and the "module" split caused by the design of bazel should not block it (it's similar in gradle support in intellij),

on top of that in bazel it's common to create a lot of build targets, just for the sake of performance which dont have a real "structure" reason, they are there just to make caching faster

@abrams27 Yeah, that makes sense. Out of curiosity: Do you need to explicitly mark those associate modules in Bazel or it this some implicit setup for tests? Can you share an example? If this is some automatic thing, it might make sense to also implement it in mill-kotlin.

you need to set it explicitly,
we have a bit of them in our tests: https://github.com/JetBrains/bazel-bsp/blob/ec256a99f85e1df882439308a6dbeb6951e28cd2/executioncontext/workspacecontext/src/test/kotlin/org/jetbrains/bsp/bazel/workspacecontext/BUILD#L7