Yes, in fact that mirrors how i had planned to tackle this.<br><br>The question is, can we put in Utility code that is separated by platform, which typically has been for Host?  This mirrors what llvm does <br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 15, 2017 at 6:29 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">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. 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 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 normally<br class="gmail_msg">
> put under Host.  I think this makes some sense.  Practically all parts of a<br class="gmail_msg">
> codebase have need of a single OS abstraction layer.  So, I think that a lot<br class="gmail_msg">
> of the functionality currently in lldbHost is in fact needed by the rest 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, and<br class="gmail_msg">
> start moving some of this code from Host down to Utility.  Doing so would<br class="gmail_msg">
> allow us to break one of the biggest links in the dependency cycle in the<br class="gmail_msg">
> entire codebase, which is that Host depends on everything, and 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 interact<br class="gmail_msg">
> with Target, with CommandInterpreter, and with many other things.  And 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.  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>