Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This PR moves the definition of the `run` targets from `JavaModule` into
`RunModule`. Also some other targets where moved, e.g. `mainClass`,
`finalMainClassOpt` and `finalMainClass`.
The advantage of having them in `RunModule` is, that one can easily
define and configure additional runners as sub-modules.
Example: Define a `daemon` sub-module which acts as runner for the
`cli.DaemonTool` class.
```scala
import mill._, scalalib._
object foo extends RootModule with JavaModule {
def mainClass = "cli.Main"
object daemon extends RunModule {
def runClasspath = foo.runClasspath
def localRunClasspath = foo.localRunClasspath
def mainClass = "cli.DaemonTool"
}
}
```
To preserve binary compatibility, all moved `def`s retain an override in
`JavaModule` and forward to their `super`-`def` in `RunModule`.
Therefore traits compiled against older versions of trait `JavaModule`
should still be runnable with newer versions.
Some `run`-targets (`run`, `runLocal` and `runBackground`) previously
required the `compile` target, since that also provided some zinc
analysis which included some main class discovery. Since the goal was to
decouple the `run` targets from the concept of compilation, I
implemented a different discovery logic for main classes which uses the
Scala API of `scalap`. This is completely newly written code but it's
only a couple of lines and all existing tests (which also include main
class discovery) succeeded. The advantage of the new logic is, that it
should work with any given classpath and also for non-Scala classes. The
new code is located in the zinc worker, since this is already shared
between all `RunModule`s, but there is no real need to have it there. To
avoid increased complexity, I resisted to introduce a new shared worker
just for the sake of technical independence, for now. The new
`allLocalMainClasses` target can be used to find all main classes in the
`localRunClasspath`. This is some useful information I needed now and
then in projects, so it makes sense to have it in a dedicated target for
better caching and easy `show`ing.
I also introduced a new `localRunClasspath` target which abstracts away
the classpath that is supposed to be produced by compilation. This is
somewhat analogue to the `testClassapth` introdcued in PR #3064. Since
both typically hold the same classpath, `testClasspath` by default uses
the result of `localRunClasspath`. We probably could remove
`testClasspath` altogether, but it's semantically bound to `TestModule`
and isn't necessarily the same as `localRunClasspath`, so I think it's
legit to keep it.
For consistency, I also added a `localCompileClasspath` which resembles
the part of the `localClasspath` which is feed into the compiler. All
added classpath targets also have a version for BSP (named with prefix
`bsp` and returning a `T[Agg[UnresolvedPath]]`) when appropriate.
Pull request: #3090- Loading branch information
