<div dir="ltr">Thanks for all of the comments. I plan to do the move for Platform/gdb-remote, platform/Android, Platform/Linux, Process/gdb-remote, Process/Linux within a week and leave the rest of the classes for now, but possibly move them in the future if my time permits.<div><br></div><div>Tamas</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 23, 2015 at 6:05 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Mar 23, 2015, at 4:20 AM, Abid, Hafiz <<a href="mailto:Hafiz_Abid@mentor.com">Hafiz_Abid@mentor.com</a>> wrote:<br>
><br>
> Jim,<br>
> The initial developers of lldb-mi perhaps did not want to use the classes from<br>
> lldb_private inside lldb-mi. So in some cases, they sort of duplicated the code<br>
> for things like Mutex in lld-mi which are already available in host layer. If there<br>
> are no objections on using lldb_private inside lldb-mi then I can remove that<br>
> code duplication.<br>
<br>
</span>Please just switch to using C++11 for the host layer stuff (std::mutex, std::condition, etc). Don't expose or copy any code. Nothing from lldb_private should be used in any code that links against the LLDB shared library. If you want internal stuff, you should switch over to be a tool that links against the internal lldb_private stuff and not use the lldb::SB API.<br>
<br>
And I do prefer that we try and use the lldb::SB API for lldb-mi.<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
<br>
</font></span></blockquote></div><br></div>