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.
On Fri, May 21, 2021 at 1:32 PM Ben Boeckel via SG15 <email@example.com> 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.