I would like to write a mill utility tool (maybe a function or Module inside build.sc) for summarizing and post processing results of various targets. Instead of hard coding all processed targets I prefer a solution that could somehow iterate the build.sc contents and produce a list of found targets from which I could then filter out e.g. other than ScalaModules etc.
What is the most elegant way to implement this kind of iterator?
That utility tool also needs to locate the dest directory of each target. Inside the target I can use T.dest but how the get the destination directory from "outside" (not running the target)?
One way to accomplish this kind of functionality is to browse recursively the directory structure under ./out but that information lacks the target type information and also target out directory is missing if it is cleaned or not yet run at all. So it is not possible to report that target Foo exists but has currently no results.
If you are just interested in the list of modules and targets, you can simple use the
resolvecommand.To apply advanced filtering, you need to do it in Scala. Mill already provides various support to access modules and targets. Just have a look at the class
mill.define.Module, which is inherited from all Mill modules. As an example: to access direct sub modules of a modulefoo, usefoo.millModuleDirectChildren. You can find more infoo.millInternal, e.g.modulesto find all sub modules, ortargetsto find all targets.You can also look at the implementation of the various built-in commands in
mill.main.MainModule. There you find various resolvers. You could even write your own to filter whatever you want. But be warned, it's far from trivial.About the
destdirectory. In general, you shouldn't even want to access this directory. It is considered an implementation detail of a target. If you have the currentmill.eval.Evaluatorat hand (e.g. within an evaluator command) to retrieve the actual usedoutdirectory, you can get the actual path used forT.destof a target withmill.eval.EvaluatorPaths.resolveDestPaths.But instead of using this, you should just use whatever a target returns. There is no necessity e.g. for a
compiletarget, that the actual compile result is located in itsT.destdirectory. Also, beware to not modify thedestdirectory or it's contents from outside, as that may break the caching mechanism.I'm referring to the latest released Mill version 0.10.5.