<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 28 June 2017 at 00:55, Boris Kolpackov <span dir="ltr"><<a href="mailto:boris@codesynthesis.com" target="_blank">boris@codesynthesis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> writes:<br>
<br>
> Assuming by BMI you mean the .pcm file, this is not true. Clang requires<br>
> both the core and extra .pcm files in this case. However, we found it<br>
> extremely impractical to explicitly pass all such .pcm files to a<br>
> compilation (and indeed on large projects doing so caused us to hit command<br>
> line length limits and generally produce *highly* unwieldy command lines),<br>
> so we do not require .pcm's that are reachable through the dependencies of<br>
> another .pcm file to be explicitly passed to the compiler -- each .pcm<br>
> stores names and relative paths to its dependencies, and we load those<br>
> dependencies as part of loading the .pcm itself.<br>
<br>
</span>Got (and tested) it, thanks. I suppose there is no reason for you to<br>
deviate from this once you support module re-export (export import M;)<br>
even though, in a sense, re-export is as-if injecting an implicit import<br>
into the consumer's translation unit?<br></blockquote><div><br></div><div>Right. From the point of view of a user of the re-exporting module, they don't depend on M, so they should not need to specify a .pcm file for M.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One thing I noticed is that there is no way to override this embedded<br>
path, at least not with -fmodule-file. This could be useful for<br>
distributed compilation since otherwise the build system will have<br>
to recreate the directory structure on the remote host.<br></blockquote><div><br></div><div>So far, we've not seen this be a problem in practice across the (small) number of build systems where we've implemented support for explicit module builds. If this is a problem for your build system, we can certainly look at adding support for overriding this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Would there be interest in having a low-level option that specifies<br>
the exact module name to module .pcm mapping and, perhaps, a second<br>
one that can read such mappings from a file? They will then override<br>
module file references in .pcm's.</blockquote><div><br></div><div>I don't think we need a mapping mechanism; giving us the module files on the command line in topological order should suffice. If we've already been handed a module file for module X, and then we load a module file for module Y that depends on X, we can simply ignore the path specified in Y's .pcm and just use the existing X .pcm. (We'd still perform the check that the X .pcm is the same as the one that Y was built against in this case.)</div><div><br></div><div>We could actually build the topological ordering ourselves, but that would require a two-pass approach for loading .pcm files; passing this burden on to the build system seems like the better tradeoff.</div></div></div></div>