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.