I actually did switch over to using a HostInfo::Initialize() as per our discussion the other day, I just didn't think to use for that for GetLLDBPath(). It's a good suggestion though, so I'll add it to my list of things to do. Feel free to remind me if enough time passes and I still haven't gotten to it.
On Mon, Aug 25, 2014 at 12:31 PM, Greg Clayton <gclay...@apple.com> wrote: > 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
