[cfe-dev] [RFC] Storing relative paths in .pcm files
richard at metafoo.co.uk
Mon Nov 17 18:27:16 PST 2014
On Mon, Nov 17, 2014 at 6:08 PM, Ben Langmuir <blangmuir at apple.com> wrote:
> Hey Richard (& cfe-dev),
> Currently if one AST file imports another (e.g. module A imports module
> B), we store the absolute path of module B inside module A’s IMPORTS
> record. When we know that both files will always be in the same directory,
> this wastes space and more importantly prevents moving those modules to
> another directory. The latter is very handy when debugging a module bug
> for which someone has given you their broken module cache.
> When an implicitly built module imports another implicitly built module,
> we can rely on the modules always being in the same module cache, and I
> think we should switch to a relative path that is either looked up relative
> to the current pcm file or the (hash-specific) module cache dir. Do you
> think we should do this for explicitly built modules that happen to be in
> the same directory?
My initial reaction is that we should preserve the path given in the
-fmodule-file= argument on the command line. If I use
-fmodule-file=x/foo.pcm and explicitly build y/bar.pcm, I think that
y/bar.pcm should say that it finds foo in 'x/foo.pcm'.
If the user then builds with -fmodule-file=z/foo.pcm
-fmodule-file=y/bar.pcm, we should probably ignore the path that was
specified for 'foo' when building 'bar'.
> What about implicitly built modules that are imported by explicitly built
It seems tricky to make that work transparently if the modules have been
relocated. We shouldn't expect that explicitly-built modules are located
anywhere near the module cache, so I guess the best we can do is to look
for such files in the module cache by default (even if the module cache has
moved), and not bother writing out /path/to/module/cache/thing.pcm. If
they've been relocated, then I suppose you could explicitly import them
However, we need to be cautious that things can change between explicit
module build and use, so we need to use the parameters from the explicit
module itself when determining the configuration hash of the implicit
module. Maybe the simplest thing to do is to skip this case for now; we'd
only be saving the space cost of writing out the path to the module cache,
and I don't think that's a big deal (at least, not compared to the 100K we
waste on a name lookup table for builtins and keywords in each module).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev