<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On 29 Jun 2017 12:13 am, "Boris Kolpackov" <<a href="mailto:boris@codesynthesis.com">boris@codesynthesis.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> writes:<br>
<br>
> I don't think we need a mapping mechanism; giving us the module files on<br>
> the command line in topological order should suffice. If we've already been<br>
> handed a module file for module X, and then we load a module file for<br>
> module Y that depends on X, we can simply ignore the path specified in Y's<br>
> .pcm and just use the existing X .pcm. (We'd still perform the check that<br>
> the X .pcm is the same as the one that Y was built against in this case.)<br>
<br>
</div>I've done some testing and this is not how it works today. Perhaps you<br>
meant it in the "could be done this way" sense.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Yes, this is a "we can" rather than a "we already do". Sorry that wasn't clear.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
BTW, I've also tested moving the entire build directory somewhere else<br>
to check if .pcm's store relative paths to each other. This does not<br>
appear to work either:<br>
<br>
fatal error: malformed or corrupted AST file: 'SourceLocation remap refers to unknown module, cannot find core.pcm'<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">We've talked about making this kind of relocation easier by allowing the module source directory and the build directory to be relocated independently (right now you need to relocate everything together -- sources, .pcm's, working directory).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On the more fundamental level, this still poses a problem if the build<br>
system needs to re-map all the .pcm files (e.g., for a distributed build):<br>
we will still have crazy-long command lines and may hit the command line<br>
limits. So, at a minimum, we seem to need a way to load the list of modules<br>
from a file.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Clang does support specifying @file on the command line to take arguments from a file, which should at least evade the command line length limit.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now, for why we may want a mapping, not just a list of .pcm's: if the list<br>
of .pcm's is stored in a file, then chances are some build systems will<br>
opt to have one file per project (or some similar granularity) rather<br>
than per translation unit. Which means not all listed .pcm's will be<br>
needed during every compilation. If it's only a list of .pcm's, then<br>
Clang will have to at least read each file, which seems like a waste.</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">True. At that point I think you'd be better off with a directory of .pcm files following a naming convention rather than providing the compiler with a (potentially very large) set of mappings (and we already support something like that). But allowing an explicit mapping to be specified would also be fine if people would actually use that facility.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">
> We could actually build the topological ordering ourselves, but that would<br>
> require a two-pass approach for loading .pcm files; passing this burden on<br>
> to the build system seems like the better tradeoff.<br>
<br>
</div>I agree. Though requiring a sorted list of modules doesn't make build<br>
system's life any easier, especially if it wants to weed out duplicates<br>
(to keep the command line as tidy as possible) and not allocate any<br>
extra memory while doing it.</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Granted. Our design right now is pretty strongly tied to having loaded all dependency modules before loading a dependent module, though, so we need that complexity somewhere.</div><div dir="auto"></div></div>