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 <sdowney@gmail.com>
Sent: Friday, May 21, 2021 1:00 PM
To: ISO C++ Tooling Study Group <sg15@lists.isocpp.org>
Cc: Gabriel Dos Reis <gdr@microsoft.com>; Ben Boeckel <ben.boeckel@kitware.com>
Subject: Re: [SG15] Scandeps format post-P1689R3 discussion

 

 

 

On Fri, May 21, 2021 at 1:32 PM Ben Boeckel via SG15 <sg15@lists.isocpp.org> 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. 

http://eel.is/c++draft/cpp.include

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.