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

[Richard Smith via cfe-dev]

On 30 June 2017 at 06:39, Boris Kolpackov <boris at codesynthesis.com> wrote:

> Richard Smith <richard at metafoo.co.uk> writes:
>
> > Because you don't use the content-addressed system locally? What we do is
> > to use symlinks for remote compilations and just put the files in the
> > "right" places locally, so the file system looks the same either way.
>
> Locally we use things as arranged by the user. For example, if project
> bar uses libfoo that contains libfoo/foo.pcm, then we will (try to)
> use this libfoo/foo.pcm where the user built it.
>
> On the build slave, however, we may be building things for multiple
> projects simultaneously and each may have its own foo.pcm. So here
> we will call it something like modules/93255[...]5f6db7.pcm.
>
> If I am able to specify the module-name to module-file mapping, I
> will be doing essentially the same thing locally and remotely:
>
> -fmodule-blah=foo=libfoo/foo.pcm
>
> -fmodule-blah=foo=modules/93255[...]5f6db7.pcm
>
>
> > 1) this is likely to end up with a set of command line arguments that
> grows
> > linearly with the total number of modules in the project, and you're
> likely
> > to find the build system needs or wants to prune the list down to just
> the
> > dependencies anyway
> > 2) we can't do any validation that the command line arguments are
> > reasonable if the corresponding module is not used (we don't want to
> stat a
> > large number of .pcm files if most of them are not going to be used, and
> > definitely don't want to read the file header to find if it names the
> right
> > module)
> >
> > I don't think (2) is really a big deal, though, since we'll get at least
> a
> > "file not found" error if the module is actually used by the compilation.
>
> Agree. It will either be detected at some point or it will be harmless.
>
>
> > And (1) is ultimately your problem as the build system maintainer, not
> > ours. ;-)
>
> Agree. Also, my plan is to have two options: one to specify the mapping
> on the command line (one entry at a time) and the other to read it from
> a file. So the file option will help build systems that, for example,
> want to specify a single (and potentially large) mapping file per project
> or some such.
>
> Which brings me to the most difficult part: choosing option names that
> everyone likes ;-). And, BTW, I am hoping to implement the same in GCC
> with the same names.
>
> So we are looking for two options, one to specify a mapping entry and
> the other to specify a mapping file with multiple entries:
>
> -fmodule-blah=<name>=<file> | -fmodule-blah-blah=<file>
>
> Here is what I came up with:
>
> (1) -fmodule=      | -fmodule-map=
> (2) -fmodule-map=  | -fmodule-map-file=
> (3) -fmodule-loc=  | -fmodule-loc-file=
> (4) -fmodmap=      | -fmodmap-file=
>
> 1. While nice and short, the use of -fmodule might be too close to
>    -fmodules. On the other hand, these options will normally be used
>    by build systems (the user will just use -fmodule-file) so probably
>    not a major issue.
>
> 2. These are nice except -fmodule-map-file is already used. One way
>    to resolve this would be to "overload" -fmodule-map-file to mean
>    something different in the -fmodules-ts mode. Though I suspect its
>    current meaning could be useful even in -fmodules-ts.
>
> 3. This is an attempt at using something other than 'map'. It has a
>    nice property of suggesting that specifying these options doesn't
>    actually cause the modules to be loaded.
>
> 4. Another play on the 'map' theme. I think it will be hard to sell
>    to the GCC folks since they don't have the -fmodule-map-file issue.
>
> Any preferences/suggestions? My favorite is (1).


-fmodule= is a little too nonspecific for my tastes; I'd expect this to do
what clang's -fmodule-name= does (that is, specify the name of the current
module) before I'd expect it to specify an external module file's path.

How about something like -fmodule-file-<name>=path?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170630/afcdbaf7/attachment.html>