+1 +1 +1

This would be very difficult to implement.

By nature, compilation is a process of unknowns. It's never all that clear how much remains to compile. To do this would require the following:

1) DM would first have to make a scan pass of the files it knows to compile, to look for includes, and then get a line length for each file so it could approximate how far along the parser was. Effectively this would be a pre-parse, increasing compile time.

2) While parsing the file, it would have to report that it's on file #N, line #M, so it could estimate how far along in the parsing process it was. Maps would have to figure into this too.

3) Generating code is a separate step, so it's unclear how the time for this would be factored in along with parse time to get a total estimated progress. However while generating, the builder would have to do something similar to the parser and report on each node so that it can (very roughly!) estimate how far along it is. Before generating, it would have to get a rough count of the number of nodes it would traverse.

A lot of the other processes like compiling resources are not time-intensive, but the parsing and generation steps would be very hard not only to reconcile with each other in terms of their contribution to total progress (ideally approximating estimated time), but also hard to measure individually.

For the time being, is there at least any way to output some sort of "progress so far" number? Even if it's meaningless between codebases, for people working on one codebase they could look at it and think "Okay, it's at , but usually the compile finishes somewhere around ..."

I think, due to how DM handles includes, that it doesn't actually work that way? I was under the impression the entire system just compiled the .dme, and that branched out to all the selected code files via the #includes in it.