Absolute paths in package.mill hinder isolated compilation of nested submodules

[Yan-Muzi]

The package declaration requirements introduced in Mill 0.12.x (#3426) create conflicts in projects with nested submodules that need to function both as project dependencies and standalone components.

Take XiangShan as an example. We have a submodule rocket-chip, which contains cde as its submodule. When cde is used in XianShan, cde directory requires package build.rocket-chip.cde. However, when we want to develop rocket-chip independently, the same cde directory now requires package build.cde.

Is there any ways to fix or bypass this?

[lefou]

I was thinking about making the top-level package configurable yesterday, e.g. for cases where build doesn't match (e.g. you want to import some library which also has top-level package build). It's not there, but it might be suitable to fix your issue as well. But at the price, that the independent project needs to use the long package as well

//| mill-root-package: build.rocket-chip

[lihaoyi]

@Yan-Muzi we don't have any first-class support for the scenario you describe. We could probably come up with something e.g. what @lefou discussed.

[Yan-Muzi]

Am I correct in understanding that I may configure the top-level package as either XiangShan or rocket-chip within cde? This sounds OK but is rather inelegant as a submodule should not be aware of its containing directory.

If relative paths are not acceptable, is it possible to define all the modules in the root directory?

[lihaoyi]

@Yan-Muzi it is possible to define all the modules in the root directory build.mill. Could you explain a bit how that would help?

[Yan-Muzi]

If all the modules can be defined in the root directory, then it is the root directory that worries about its submodules instead of otherwise. This seems better because a git repository has all the information of its submodules, while it is unaware of how it will be used in other repositories as submodule.

For example, in a repository with nested submodules like this:

├── build.mill
└── submodule-A/
    └── build.mill
    └── subsubmodule-B/
        └── build.mill

build.mill in root directory can describe how submodule A and subsubmodule B are be used in the project, and build.mill in submodule A can describe how it uses subsubmodule B, which are different as the former is package build.submodule-A.subsubmodule-B while the latter is package build.subsubmodule-B. In this way, submodule-A can compile alone without the information of root directory.

[lihaoyi]

@Yan-Muzi got it. I think we may have some sanity-check assertions that yell at you if you have a build.mill in a sub-folder, because it's a pretty easy mistake to make when people should create a package.mill folder instead. But maybe we can offer some way to silence that error

[Yan-Muzi]

Looking back on #3426, I found this:

We can look into making package declarations optional again in future, but for now this gives us working IDE support with minimal effort, converging with vanilla Scala, at the cost of a little boilerplate per-file.

Optional package declarations should solve this issue elegantly! Looking forward to this new feature.