When running the testsuite, the LLDB shlib is a symlink to its actual location, so finding shlib-relative resources can be problematic. This patch fixes that by resolving symlinks.
Diff Detail
Event Timeline
include/lldb/Host/FileSpec.h | ||
---|---|---|
516 | rename to ResolveSymbolicLink? | |
source/Host/common/FileSpec.cpp | ||
818 | rename to ResolveSymbolicLink() and return a copy of this object if it isn't a symbolic link | |
source/Host/common/HostInfoBase.cpp | ||
310–312 | No need to check if we change the behavior of ResolveSymbolicLink, this code will just be: lldb_file_spec = lldb_file_spec.ResolveSymbolicLink(); |
Can you move this to FileSystem.h? I don't think we should be adding more
things that hit the file system to FileSpec. That's exactly the reason
FileSystem.h exists, because many of the operations will be implemented
differently across platforms, so we should be using the Host layer.
Furthermore, FileSpec can refer to a remote path, so you can't even
guarantee that the OS you're on is the same OS as that which the path
refers to. So another reason why putting this in FileSpec doesn't make
sense in my opinion.
Thanks! Feel free to leave the method in Host/windows/FileSystem.cpp
empty, i'll fill it out.
At zturner's suggestion, moved the function to FileSystem and renamed it to be more consistent with what other FileSystem functions are called.
If you change the name back to ResolveSymbolicLink or GetSymbolicLinkTarget, then this looks fine.
include/lldb/Host/FileSystem.h | ||
---|---|---|
43 ↗ | (On Diff #35143) | I'd rather not call it realpath, because even though realpath is the way it will be implemented on non-Windows platforms, realpath has some subtleties in its semantics. So anyone reading this function name will expect that it has realpath semantics, even though some of the semantics are only well-defined in the context of a posix-like file system. I actually like your original name ResolveSymbolicLink better, because the behavior is narrow enough that it's easy to implement everywhere, and we don't have to worry about these little edge cases. |
Restored the old name based on zturner's suggestion that Realpath() is too specific and has semantics that Windows wouldn't honor.
rename to ResolveSymbolicLink?