On Mon, Feb 11, 2019 at 4:39 PM Matthew Woehlke <mwoehlke.floss_at_[hidden]>
wrote:

>
> I'm not sure what "linearize" means here? I'm also not sure how it
> helps; until you know what generates that module, you can't build the TU
> that depends on it.
>
> 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.

> and when you find the interface unit that produces module_name, write out
> > the build dependency there.
>
> That's basically how CMake works for Fortran.
>
> > This works less well for external dependencies.
>
> Well, for external dependencies, you just assume that the information
> how to generate their BMI's already exists (as per discussion in my
> previous message). If you don't find a module *at all*, that's a hard
> build error. Plausibly the collator could detect this, but I'd be fine
> with the compiler just croaking because it can't import the module.
>
> > 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. There's lots of reasons incremental builds get invoked. This is
equivalent to a missing header file. I might have not written it yet, or
added the target dependency, or installed the package, etc. I don't mean
the case where the bmi doesn't exist. That's the normal case. But the
scanner can't assume that the build has built everything, so it has to be
more forgiving. But that means more errors downstream.