[Tooling] Modules feedback

Matthew Woehlke mwoehlke.floss at gmail.com
Thu Feb 14 22:19:44 CET 2019


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


More information about the Tooling mailing list