In general, I'm wary of tools that try to analyze dependency information on their own ("best-guess" dependency analysis). -MMD and /showIncludes are preprocessor directives, but they are usually used in the context of a full TU compilation (in the case of tools attempting to extract dependency information, such as Ninja). As far as I am aware, tools using these options for dependency information are already performing full semantic analysis as part of dependency extraction. I anticipate that it will be similar with modules.

Adding features to explicitly allow tools to do "best-guess" dependency analysis feels too close to promoting what *I* consider bad behavior, but I'm very opinionated on the subject. Others may have differing opinions.

In general, I'd rather make tools that behave more correctly (and facilitate the creation of those tools through language and library design) than to try and cater to tools that do things poorly.

On Sat, Dec 1, 2018, 08:38 JeanHeyd Meneide < wrote:
Dear SG15,

     I wanted to move away from the talk of package managers and other such things for a bit, to talk about something closer to the build system. Dependency management is becoming a bit of a hot topic now that modules have been pushed to Core for wording review. std::embed (p1040) is facing significant uphill challenges because it requires full Semantic Analysis to communicate dependency information, which is a no-go for preprocessor scanners and things like /showIncludes or -MMD.

     To address the problem of dependency tracking for a source file, I wanted to add a module directive called module-requires, p1130.

     This paper is supposed to allow folks the ability to say "some resource out there should trigger a re-compile of this file / module if it ever changes". If we get module:private;, we could tag it to the module's implementation only as well.

Any thoughts?

JeanHeyd Meneide
Tooling mailing list