[Tooling] [ Modules and Tools ] Tracking Random Dependency Information
Colby Pike
vectorofbool at gmail.com
Sun Dec 2 05:50:19 CET 2018
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 gmail.com 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 isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/tooling
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20181201/1207a946/attachment.html
More information about the Tooling
mailing list