On 11/02/2019 16.59, Steve Downey wrote:
> Being able to do a linear scan without backtracking or keeping extra
> state, rather than finding the source interface unit that would generate
> the bmi to emit a dependency directly on it.

I'm not sure the build tool (meaning, in this case, e.g. make or ninja,
not e.g. CMake, meson, etc.) can work that way.

Remember, these dependencies have to be injected *during the build*.
That means each TU must be stalled not only until its dependencies are
known (easy), but until *the edges that will satisfy those dependencies*
are known.

It's not a case of "backtracking" or "keeping extra state". It's a case
of not being able to proceed until the build graph, at least upstream of
a TU, is complete.

> On Mon, Feb 11, 2019 at 4:39 PM Matthew Woehlke wrote:
>>> There's also the additional complication that the imported module name
>>> may not exist yet. That should be a build error
>>
>> No, it should *work*. Again, this isn't a problem in the approach CMake
>> uses for Fortran modules.
>
> If it doesn't exist because I'm in the middle of adding it, or misspelled
> it, etc.

Ah, I see... I misread your "yet" as "we haven't scanned the thing that
will provide it yet" or "we haven't run the build rule to generate the
thing that will provide it yet". You meant that it doesn't exist *at
all*. Yes, that (as noted in my previous message) can just be a build
error. Actually, you make a good point that having be a *compile* error
and not a scan/collate error makes sense.

On 11/02/2019 17.23, Ben Boeckel wrote:
> I'd *much* rather the scanner error out saying "no such file to scan"
> than later getting "no such module found". Your approach is even worse
> is an incorrect build because a stale module gets found[1]. The deferred
> error implies that broken builds are tolerated instead of being called
> out at the point of first detection.

...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?

I think this may only work if the build system has already been told to
expect a foo.cpp that doesn't exist yet. But that is an error today (at
*configure* time, even).

That said, this does suggest that a way to only consider "known"
modules, at least for the local build directory, might be useful...

-- 
Matthew