[cfe-dev] Modules TS: binary module interface dependencies

[Richard Smith via cfe-dev]

On 28 June 2017 at 00:55, Boris Kolpackov <boris at codesynthesis.com> wrote:

> Richard Smith <richard at metafoo.co.uk> writes:
>
> > Assuming by BMI you mean the .pcm file, this is not true. Clang requires
> > both the core and extra .pcm files in this case. However, we found it
> > extremely impractical to explicitly pass all such .pcm files to a
> > compilation (and indeed on large projects doing so caused us to hit
> command
> > line length limits and generally produce *highly* unwieldy command
> lines),
> > so we do not require .pcm's that are reachable through the dependencies
> of
> > another .pcm file to be explicitly passed to the compiler -- each .pcm
> > stores names and relative paths to its dependencies, and we load those
> > dependencies as part of loading the .pcm itself.
>
> Got (and tested) it, thanks. I suppose there is no reason for you to
> deviate from this once you support module re-export (export import M;)
> even though, in a sense, re-export is as-if injecting an implicit import
> into the consumer's translation unit?
>

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.

One thing I noticed is that there is no way to override this embedded
> path, at least not with -fmodule-file. This could be useful for
> distributed compilation since otherwise the build system will have
> to recreate the directory structure on the remote host.
>

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.

Would there be interest in having a low-level option that specifies
> the exact module name to module .pcm mapping and, perhaps, a second
> one that can read such mappings from a file? They will then override
> module file references in .pcm's.


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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170628/3bb6529d/attachment.html>