Correct.  Part of the reason why I would prefer if we stayed away from filepath in spec as much as possible.


PS: I have been conducting some small scale experiments with the various build systems around (that claim to have some support for ++ Modules) and insisting to express things in terms of files instead of targets (that can have internal tracking) has been frustrating.  So, I would really love for us to move away from that.


-- Gaby


From: Steve Downey <>
Sent: Friday, May 21, 2021 1:00 PM
To: ISO C++ Tooling Study Group <>
Cc: Gabriel Dos Reis <>; Ben Boeckel <>
Subject: Re: [SG15] Scandeps format post-P1689R3 discussion




On Fri, May 21, 2021 at 1:32 PM Ben Boeckel via SG15 <> wrote:

On Fri, May 21, 2021 at 17:12:10 +0000, Gabriel Dos Reis wrote:
> > How about a `lookup-method` with a limited set of values would make
> > sense? `by-name`, `by-local-path` (""), `by-path` (<>)?
> I know the build system works primarily on filepaths, but from the
> source and compiler point-of-view, they may not be "by path".  Which
> is why I suggested "angled" and "quoted".

`include-angle` and `include-quote`? Does the standard have better names
for these things?

Not really. The form 
# include < h-char-sequence > new-line 
imports a header, while the form
# include " q-char-sequence " new-line 
imports a source file, because headers aren't necessarily source files, and might be magic. But that's likely to confuse everyone. And if a "source file" isn't found, it's reprocessed as a header.

It shouldn't matter too much for this, but it's worth keeping in mind that `make` doesn't work with paths, it works with targets, and spelling counts, even if they refer to the same path. That is ./path/file.h and ./path/something/../file.h have no relation to each other from make's point of view.