Sorry to take so long to get back on this one.

> 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 believe convincing can be done in this regard. I'm not proposing that
implementers add support for this as part of the preprocessor, but rather
as another compiler option. Modern build tools such as Ninja grab the
dependency information for a translation unit as part of invoking the
compiler command, not by running the preprocessor separately. I'm preparing
a post on how Ninja builds and performs dependency analysis, which I
believe is the currently optimal way to do it. There may be some tweaks
with the addition on modules, but it will still be applicable.

In short: Implicit dependency information is generated on-the-fly by the
edge command as part of regular edge execution. Not only is semantic
analysis executed, but the entire compilation process.

On Tue, Dec 4, 2018 at 6:50 PM JeanHeyd Meneide <phdofthehouse_at_[hidden]>
wrote:

> Dear SG15,
>
> To address one of the previous concerns, I've made sure to
> specifically add a call out a new Word of Power in this proposal:
> https://thephd.github.io/vendor/future_cxx/papers/d1130.html#wording-intent.
> It's called *resource-location* or *resource-locations*. This will give
> std::embed and other proposals a well-defined way of referring to a lookup
> mechanism. It is still implementation-defined where this comes from, but
> just like include paths I expect this to come from a Resource Path command
> line parameter that build systems can tap into.
>
> If you have any other concerns or questions, please do let me know!
>
> Sincerely,
> JeanHeyd Meneide
>
> On Mon, Dec 3, 2018 at 6:13 AM JeanHeyd Meneide <phdofthehouse_at_[hidden]>
> wrote:
>
>> > That's insufficient: to be usable, it must also say that it is
>> > *the same* for all resource strings, regardless of which facility
>> > (std::embed, etc) they are used in.
>>
>> Resource lookup will be exactly what is written in this paper, so long as
>> I can get consensus and move this through the Committee. As the author of
>> std::embed, I have the privilege of moving these papers in sync. Should
>> p1130 be accepted, std::embed will be updated to specifically call out
>> Resource Lookup, as defined in [module.requires] (or whatever it ends up
>> being).
>>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>