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