As a final cleanup to these changes, can we get get rid of the preprocessor macro in the HostInfo::GetLLDBPath() and change over to using std::once, or switch to using a static HostInfo::Initialize()?
> On Aug 25, 2014, at 11:42 AM, Zachary Turner <ztur...@google.com> wrote: > > I've had some questions (both privately and in responses to other messages > on-list) about Host and HostInfo. So I'll explain here in hopes of answering > for everyone. > > First, the rationale: Host was getting too big and was starting to turn into > something like "well, I need to call a platform-specific API, I'll make it a > static method in Host.cpp". As the platform matrix grows, so does the > complexity of managing this file. Second, there was no attempt in Host.cpp > to group logically similar methods together in classes. There were > filesystem methods, process spawning methods, thread manipulation methods, > methods to query the value of various os magic numbers, etc. As I started > thinking about what will need to happen to support various things on Windows, > I imagined this file exploding in complexity. Even with HostWindows.cpp, you > can see from looking at Host.cpp that it's not always possible or easy to > separate platform-specific logic into the platform specific Host files. > > So this refactor attempts to address all of these issues. > > So far I've been focused on (and mostly completed) moving code from Host into > two different classes: Filesystem and HostInfo. > > HostInfo - answers queries about the operating system that LLDB is running > on. Think of this class as being "const". It doesn't modify your OS. If > you want to know how much memory is available, or the page size, or the path > to lldb.exe, you ask HostInfo. Instead of #include "Host.h" and writing > Host::method(), you #include "HostInfo.h" and write HostInfo::method(). When > adding new methods, put your method in the least-derived class possible where > it makes sense and will compile on all corresponding platforms. > > The advantage to this approach is that > a) No matter what host OS you're on, you always have all the functionality of > that host OS available to you through static binding (e.g. no casting to a > derived type) > b) Almost zero pre-processor complexity > > FileSystem - Has methods like MakeDirectory, RemoveDirectory, GetPermissions, > etc. Where before you would #include "Host.h" and write > Host::MakeDirectory(), now you #include "FileSystem.h" and write > FileSystem::MakeDirectory(...). > > Remaining work to be done: > 1) Nuke DynamicLibrary and use LLVM's > 2) Make a HostProcess instantiatable, non-static class, which represents a > process which is running on the Host OS. Move code from Host.cpp over there. > 3) Make a HostThread instantiatable, non-static class, which represents a > thread inside of a process on the Host OS. Move code from Host.cpp over > there. > 4) Make a HostProcessLauncher class, of which derived implementations would > be WindowsProcessLauncher, PosixSpawnProcessLauncher, XpcProcessLauncher, > etc. Move code from Host.cpp over there. > 5) Update Process plugins to use the appropriate HostProcessLauncher classes > 6) Delete Host.cpp, as there will be no code left in it anymore. > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
