Allow Mill CLI to select the meta-build frame it operates on

[lefou]

Add a new CLI option --meta-level accepting an Int. Default is 0 and means the root project, 1 is the parent meta-build, if defined, or the built-in bootstrap module, and so on.

This is a first draft, to get more familiar with the recursive but mutable nature of our meta-build support.
Don't hesitate to point out shortcomings.

• Fixes Suport running tasks on a bootstrap module (--meta-level) #2658

Review by @lihaoyi

Example: Find version updates in the meta build

Here is some example output (applied to the mill repo):

$ mill --meta-level 1 mill.scalalib.Dependency/showUpdates
[1657/1657] dev.run 
Found 3 dependency update for 
  net.sourceforge.htmlcleaner:htmlcleaner : 2.25 -> 2.26 -> 2.27 -> 2.28 -> 2.29
  com.lihaoyi:mill-contrib-buildinfo_2.13 : 0.11.2-6-261437 -> 0.11.2
  com.github.lolgab:mill-mima_mill0.11_2.13 : 0.0.23 -> 0.0.24

Meta information about the build

I also added a new external module mill.runner.MillBuild to get some meta-information about the project, for now, the meta-module count or frame count.

Here on a project with one meta-build:

$ mill show mill.runner.MillBuild/levelCount
3

Pull request: #2719

[lihaoyi]

The approach looks reasonable. Maybe one quibble is with the naming --frame. "Frame" isn't a term we use anywhere else in the user-facing documentation. Maybe we can call it --meta-build-level or --mill-build-level or something similar to that, since "Meta Build" and mill-build/ are both things that the user would likely encounter in the course of working with Mill? We don't expect this to be support commonly used, so having the flag be a bit more verbose is not a problem

[lefou]

What about --meta or --meta-level?

[lihaoyi]

Sure that works. But I'd err on the side of "more verbose" since we don't expect this flag to be commonly used

[lolgab]

In the context of #1751 what I want is a way to run a target on all the levels, meta and non-meta.

This:

mill --meta-level 1 mill.scalalib.scalafmt.ScalafmtModule/reformatAll sources

requires me to know how many meta levels I have and also to run the target n times (once for every level).

I'm thinking (and please let me know it has problems) on something like:

mill --include-build mill.scalalib.scalafmt.ScalafmtModule/reformatAll sources

or something along those lines which would run a command on all levels, from meta-build to non-meta.

[lefou]

@lolgab Yeah, I also want sometimes to be able to run something on all levels. This PR is a first step, to be able to request to run targets on any specific level, which was not possible before. Once, we have that working, we can add more features.

From a high level view, what you want should be rather simple to implement, as we just need to aggregate all runs of all levels. But devil is in the details. Currently, we have different evaluators for each level, and the logic to aggregate results is also in the evaluator. Also parallelization logic is in the evaluator. So, some more work and refactoring is necessary. Whereas explicitly selecting one level is a rather easy goal to achieve.

I'm even not sure if it is possible at all to run targets from all levels at the same time, as evaluation of meta-build can affect the effective module and target relations on dependent levels. So maybe, we will never be able to parallelize evaluation of different levels.

[lolgab]

Is there a reason why we don't use default values here? val metaLevel: Int = 0 which should be supported by mainargs?

[lefou]

Defaults are provided in the apply method.

metaLevel: Option[Int] = None

Using Option[Int] in contrast to Int is more explicit whether the user provided a value or not.

[lefou]

This PR is ready for review. @lihaoyi @lolgab