On 12/02/2019 09.08, Ben Boeckel wrote:
> On Mon, Feb 11, 2019 at 19:39:39 -0500, Matthew Woehlke wrote:
>> ...but how does the build system know? If I write 'import foo', and
>> 'foo' is supposed to be a source that I haven't written yet, how does
>> the build system tell the difference between that and a 'foo' that came
>> from system packages?
>
> There are 3 possibilities that I see:
>
> - It comes from a source that is supposed to be scanned during the
> build already. If that isn't scanned, not finding the `foo.mod` is a
> compiler error. This is exactly the same as a generated header the
> build system doesn't know about missing at compile time. The error
> is in not telling the build tool about the source containing the
> module.
> - It is external and implicitly compiled via compiler magic. The
> compiler must tell the build system where this is being done during
> `scan` and the resulting output file of the implicit module. The
> `collate` step in this case handles hooking up dependencies
> properly.
> - It is the build tools's job to be told about modules from external
> dependencies. Then it is on the author of the build tool input to
> add this rule (whether done manually, via CMake's usage
> requirements, pkg-config entries, etc. is an implementation detail).
>
> None of these require silencing errors about missing inputs from the
> `scan` step. Are there other cases that I'm missing that still results
> in a "correct" build?

I think the objection was that I want to try to do as much as possible,
e.g. build other TU's, if a dependency is missing. Making this a scan
error would prevent me building other TU's in the target that has the
problem, even though those might build successfully.

-- 
Matthew