`semanticDbData` fails on `--meta-level 1` about mill HOT 4 CLOSED

T.workspace exists to avoid the use of os.pwd (As it forces us the always run any Mill tooling in a process bound to that working dir and prohibits future Mill servers that can be shared for multiple projects for example). I think we should change T.workspace to always point to the outer project directory. Although, I said that meta-builds are inaware of their outer builds, that is not completely true. It in deed depends on $-imports of the outer builds. We can still add dependencies with import $ivy. Also, the used Mill version is configured in the outer build. We also special configure the out-dir to be a sub-directory of the outer out-dir. Also @lihaoyi mentioned in a previous discussion about meta-builds, that these were not designed to be re-used by multiple projects. We can't freely use arbitrary projects as meta-builds. Additionally, any meta-build inherit from a special MillBuildRootModule which itself provide API with information about the outer project. All these indicate, that sharing the T.workspace with the top-level project isn't totally wrong.

from mill.

I had kind of the same issue with ScalafmtModule and --meta-level 1, but I think, changing the status quo it is a twofold sword. On the one side, the meta-project is completely separate and has no information about the fact that there is a outer module. On the other side, esp. in the context of remote caching, it's problematic that some source files (e.g. the build.sc) are outside of the workspace.

I currently think the name workspace pretty much should always refer to the whole project and we should change the current behavior. If we really need the effective mill project root, which probably relates to the source path of the root module, we should add a new accessor. Would be nice have have some more opinions on that matter. @lihaoyi maybe?

from mill.

TBH I'm not sure what the best thing to do here is. I think workspace referring to mill-build/ is great, but as you said having files outside it is problematic. IIRC there were also BSP limitations where we couldn't have multiple modules with the same content root.

from mill.

Do we have a decision on what we should do? If I know what we want, I can try to contribute a fix.
We could also avoid setting the sourceroot in semanticdb if it doesn't exist (it defaults to the current working directory).

from mill.