Having FileSpec in Utility and FileSystem in Host would work for now.<br><br>Any opinions on the FileSpec interface?  Llvm's path and file system libraries use free functions for everything.  in a perfect world I feel that's the best design, and with lldb we could even do slightly better and make all functions pure (returning copies instead of mutating) since everything is ConstString.<br><br>If we were starting over from scratch this would definitely be the way to go imo, but I'm not sure if it's worth the effort now.  What do you think?<br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 15, 2017 at 7:34 AM Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right, I see. In that case, I guess my response would be "let's wait<br class="gmail_msg">
and see how things look like after FileSpec is moved".<br class="gmail_msg">
<br class="gmail_msg">
I kinda like how we have the all the host code in a separate module (I<br class="gmail_msg">
expect we will have a lot more of it than llvm), but I am not against<br class="gmail_msg">
it if it turns out there is no other way to organize dependencies. I<br class="gmail_msg">
just don't think we've reached that point yet -- right now I don't see<br class="gmail_msg">
why we couldn't have FileSpec in Utility and FileSystem in Host.<br class="gmail_msg">
<br class="gmail_msg">
Or have you thought ahead and found a problem already?<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On 15 February 2017 at 15:17, Zachary Turner <<a href="mailto:zturner@google.com" class="gmail_msg" target="_blank">zturner@google.com</a>> wrote:<br class="gmail_msg">
> Yes, in fact that mirrors how i had planned to tackle this.<br class="gmail_msg">
><br class="gmail_msg">
> The question is, can we put in Utility code that is separated by platform,<br class="gmail_msg">
> which typically has been for Host? This mirrors what llvm does<br class="gmail_msg">
> On Wed, Feb 15, 2017 at 6:29 AM Pavel Labath <<a href="mailto:labath@google.com" class="gmail_msg" target="_blank">labath@google.com</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> I agree that the next module that needs figuring on is the host one.<br class="gmail_msg">
>> However I am not sure if the decision on what to put in what module<br class="gmail_msg">
>> should be motivated by the FileSpec class, as I think it's current<br class="gmail_msg">
>> interface has a some issues, and our choice on how to resolve them can<br class="gmail_msg">
>> greatly affect what things it depends on.<br class="gmail_msg">
>><br class="gmail_msg">
>> The main thing that bugs me with FileSpec is that it is used for a two<br class="gmail_msg">
>> distinct purposes:<br class="gmail_msg">
>> - manipulations on abstract path names (e.g. PrependPathComponent)<br class="gmail_msg">
>> - manipulations of actual files present on the host (e.g.<br class="gmail_msg">
>> MemoryMapFileContents)<br class="gmail_msg">
>> For the first one you don't need the files to exist on the host (in<br class="gmail_msg">
>> fact they may not even use the same path syntax as the host). For the<br class="gmail_msg">
>> other one, they *must* exist and *must* use the same path syntax. This<br class="gmail_msg">
>> is currently not very well separated and enforced, and I think it<br class="gmail_msg">
>> should be. I believe this is the reason the FileSystem pseudo-class<br class="gmail_msg">
>> was created.<br class="gmail_msg">
>><br class="gmail_msg">
>> So, my counter-proposal would be to finish moving the host-specific<br class="gmail_msg">
>> things out of the FileSpec class (basically just replace<br class="gmail_msg">
>> file_spec.Foo(...) with FileSystem::Foo(file_spec, ...). At that point<br class="gmail_msg">
>> FileSpec should only depend on string manipulation functions, and we<br class="gmail_msg">
>> should be able to move it without much hassle. After that, we can take<br class="gmail_msg">
>> another look and decide what to do next.<br class="gmail_msg">
>><br class="gmail_msg">
>> The thing I really like about this idea is that we will end up with<br class="gmail_msg">
>> two classes that very closely mirror llvm functionality (FileSpec is a<br class="gmail_msg">
>> version of Support/Path.h that does not assume host path syntax,<br class="gmail_msg">
>> FileSystem is similar to Support/FileSystem.h, but it supports some<br class="gmail_msg">
>> more fancy operations like mmap()). Then we could proceed to merge<br class="gmail_msg">
>> this functionality with llvm pretty much independently of any other<br class="gmail_msg">
>> refactoring we will be doing.<br class="gmail_msg">
>><br class="gmail_msg">
>> What do you think?<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> On 15 February 2017 at 01:48, Zachary Turner via lldb-dev<br class="gmail_msg">
>> <<a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">
>> > After <a href="https://reviews.llvm.org/D29964" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D29964</a>, we finally have a starting point<br class="gmail_msg">
>> > at<br class="gmail_msg">
>> > which we can begin unravelling the cross-project cyclic dependencies in<br class="gmail_msg">
>> > LLDB.  lldb/Utility now is very similar in spirit to llvm/Support.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > But llvmSupport goes one step further and includes what lldb would<br class="gmail_msg">
>> > normally<br class="gmail_msg">
>> > put under Host.  I think this makes some sense.  Practically all parts<br class="gmail_msg">
>> > of a<br class="gmail_msg">
>> > codebase have need of a single OS abstraction layer.  So, I think that a<br class="gmail_msg">
>> > lot<br class="gmail_msg">
>> > of the functionality currently in lldbHost is in fact needed by the rest<br class="gmail_msg">
>> > of<br class="gmail_msg">
>> > LLDB.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > So, I wonder if it makes sense to follow the path that LLVM has taken,<br class="gmail_msg">
>> > and<br class="gmail_msg">
>> > start moving some of this code from Host down to Utility.  Doing so<br class="gmail_msg">
>> > would<br class="gmail_msg">
>> > allow us to break one of the biggest links in the dependency cycle in<br class="gmail_msg">
>> > the<br class="gmail_msg">
>> > entire codebase, which is that Host depends on everything, and<br class="gmail_msg">
>> > everything<br class="gmail_msg">
>> > depends on Host.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > Of course, it can't just be a straight move.  Some things in Host<br class="gmail_msg">
>> > interact<br class="gmail_msg">
>> > with Target, with CommandInterpreter, and with many other things.  And<br class="gmail_msg">
>> > stuff<br class="gmail_msg">
>> > going into Utility can't take a dependency.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > So there will be some splitting, some moving, some refactoring, etc.<br class="gmail_msg">
>> > But to<br class="gmail_msg">
>> > me tackling Host seems like the logical next step, in large part because<br class="gmail_msg">
>> > Host is where FileSpec is, and it's going to be hard to break any<br class="gmail_msg">
>> > dependencies without first addressing FileSpec.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > The way LLVM handles cross-platform differences in Support is that you<br class="gmail_msg">
>> > include a single header and it does conditional includes into a platform<br class="gmail_msg">
>> > specific subdirectory for the parts that differ.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > I'm thinking to follow the same pattern here in lldb/Utility, and begin<br class="gmail_msg">
>> > looking for ways to get pieces of Host down into Utility this way, until<br class="gmail_msg">
>> > ultimately I can get FileSpec down there.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > Thoughts?<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > _______________________________________________<br class="gmail_msg">
>> > lldb-dev mailing list<br class="gmail_msg">
>> > <a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a><br class="gmail_msg">
>> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class="gmail_msg">
>> ><br class="gmail_msg">
</blockquote></div>