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 <phdofthehouse_at_[hidden] 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
> <https://thephd.github.io/vendor/future_cxx/papers/d1040.html>) 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
> <https://thephd.github.io/vendor/future_cxx/papers/d1130.html>.
>
> 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?
>
> Sincerely,
> JeanHeyd Meneide
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>