Thank you for your early feedback! I've tweaked the proposal a bit. More specifically...

     Currently, dependency generation does not perform full semantic analysis. In most cases, it does only full preprocessing plus maybe some small amount of manual resolution, but that is as far as MMD and other dependency tools go. Speaking to the Engineering Manager of the Clang Frontend Team at Apple and listening to the concerns of other compiler implementers in the room, forcing full semantic analysis to do dependency graph generation for consumption by the build system or others is a no-go for many of them. This is one way to resolve their concerns. If someone could get all of them 100% on-board with doing full semantic analysis for dependency analysis, then I could just tank this paper entirely. I would actually be 200% on board with that. But, I don't see it happening anytime soon.

     I added a clause to the paper's wording that the lookup is implementation defined. This is exactly how include path lookup resolution is defined. In this case, we expect compiler vendors to be well-behaved and to provide "/RESOURCE:" or "-resource=" path flags. Given that these would be command line flags, the build system should have access to them. In -MMD and /showIncludes modes, resolution of the module-requires can be placed into those same dependency graph formats as they exist today after the compiler resolves the resource paths as well. There is no standards-sanctioned way to say how the lookup path should be resolved (similar to include paths and modules right now), and I'd like to not invent anything that might turn out to be brittle or unused in this paper.

JeanHeyd Meneide

On Sun, Dec 2, 2018 at 10:03 AM Boris Kolpackov <> wrote:
JeanHeyd Meneide <> writes:

>      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".
> Any thoughts?

The immediate problem is with the interpretation of the "resource
string": the build system should be able to resolve it to the same
thing as the facility (e.g., std::embed) that it is used with. As
it is now, there is neither an indication of what facility each
string is for nor any specification of the resolution mechanism.
I believe you will need to add at least one of these to make this
Tooling mailing list