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

Colby:
     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.

Boris:
     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.

Sincerely,
JeanHeyd Meneide


On Sun, Dec 2, 2018 at 10:03 AM Boris Kolpackov <boris_at_[hidden]>
wrote:

> JeanHeyd Meneide <phdofthehouse_at_[hidden]> 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
> usable.
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>