benlangmuir added a comment. > Given the two-path solution, another thing we could do in the first path, is > to default to the remove_dots() version for the source, i.e. > "/install-dir/lib/clang/3.8.0/include" instead of > "/install-dir/bin/../lib/clang/3.8.0/include". The path after remove_dots() > might be different from what realpath() would return (but this is covered in > the 2nd path) but at least we canonicalize for a future virtual path request > (which can safely request the VFS based on the returned path from > remove_dots()). What do you think about it?
I'm not sure I understand how the 2nd path would cover the realpath case. It is just an entry for the realpath itself; that doesn't help if the client looks up "/install-dir/lib/clang/3.8.0" directly (not just from removing dots from bin/..). > Correct me if I'm wrong, but do you suggest we have a new entry type in the > YAML file for declaring symlinks? Right now, we handle symlinks by copying > them out as real files inside the VFS. However, adding extra "name" entries > to map for real paths for such symlinks inside the YAML should do it. Yes, that's what I'm suggesting. http://reviews.llvm.org/D17104 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
