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

[Boris Kolpackov via cfe-dev]

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

Thanks,
Boris