[Lldb-commits] [PATCH] Skip symlinks to the original file when searching for debug info

[jingham at apple.com]

That is not how we thought of FileSpec originally.  It clearly was meant to deal with real files (for instance it has Exists methods & Read, etc.)  It was meant to be a wrapper that would allow us to do all the useful file manipulation in a system-independent way.  It ended up with system dependencies just because we didn't have the time to keep it clean when there were no ports of lldb that weren't Unix...  But that's life, not design.

Anyway, it would be weird to have some object you use to denote the files you are interested in, but then when you actually want to do something with them, you have to turn around and use another object.  And it would be unfortunate to have to write system specific code at this point except for the - hopefully very few - cases where the sort of thing we want to do to a file is not able to be expressed in a system-independent way.

Jim


> On Feb 23, 2015, at 12:35 PM, Zachary Turner <zturner at google.com> wrote:
> 
> In http://reviews.llvm.org/D7836#128456, @jingham wrote:
> 
>> Shouldn't this be a method on FileSpec.  It would be fine to back it with the llvm function, but it's weird to have to use a mixture of FileSpec & lower-level llvm file system calls.
>> 
>> Jim
> 
> 
> I'm actually a fan of the lower level file-system api calls because it makes it clear to the reader that host-specific code is going to execute.  I actually wish FileSpec didn't even expose any host-specific operations, but it's hard to revisit that design now that it's in the public api.  There's Host::FileSystem which could be a good place for it.  But I kind of don't like the idea of FileSpec exposing a method that actually hits the host file system.  It's kind of a fine line, I agree, but I just envision FileSpec as something that manipulates paths.  This opens up the possibility of using FileSpecs to represent paths on remote hosts, for example.
> 
> 
> http://reviews.llvm.org/D7836
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> 
>