<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 11, 2019 at 4:39 PM Matthew Woehlke <<a href="mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I'm not sure what "linearize" means here? I'm also not sure how it<br>
helps; until you know what generates that module, you can't build the TU<br>
that depends on it.<br>
<br></blockquote><div> 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. <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> and when you find the interface unit that produces module_name, write out<br>
> the build dependency there.<br>
<br>
That's basically how CMake works for Fortran.<br>
<br>
> This works less well for external dependencies.<br>
<br>
Well, for external dependencies, you just assume that the information<br>
how to generate their BMI's already exists (as per discussion in my<br>
previous message). If you don't find a module *at all*, that's a hard<br>
build error. Plausibly the collator could detect this, but I'd be fine<br>
with the compiler just croaking because it can't import the module.<br>
<br>
> There's also the additional complication that the imported module name may<br>
> not exist yet. That should be a build error<br>
<br>
No, it should *work*. Again, this isn't a problem in the approach CMake<br>
uses for Fortran modules.<br>
<br></blockquote><div>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. <br> </div></div></div>