<div dir="ltr">I hate them too. The amount of effort I spent removing them from Host (even though there's still some there) is a testament to that. But we already have enough external dependencies on Windows as is (building Python is already a huge chore, for example), and adding more to the mix is kind of a blocking issue for me unless it's for really critical functionality. Windows is in the unfortunate position of it being a pain to build most open source libraries. I don't want to make it even harder for people to build LLDB on Windows just because of an xml library.<br></div><br><div class="gmail_quote">On Tue, Mar 31, 2015 at 4:36 PM Vince Harron <<a href="mailto:vince@nethacker.com">vince@nethacker.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I hate ifdefs, especially the ones that we've added to the code. I would hate to see any others go in. It's our plan for example to remove ifdefs that we have added .</p>
<div class="gmail_quote">On Mar 31, 2015 4:28 PM, "Zachary Turner" <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As long as it's possible to build lldb without it I'm fine with whatever, including downloading it separately, building it, and referencing it externally. But I don't want it to be a forced dependency.<br></div><br><div class="gmail_quote">On Tue, Mar 31, 2015 at 4:19 PM Vince Harron <<a href="mailto:vince@nethacker.com" target="_blank">vince@nethacker.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I really don't want LLDB to embed a copy of libxml2. I think we should build it externally and reference it from LLDB. Systems with package managers can get this trivially. Windows can download and build all dependencies with one script.</p>
<div class="gmail_quote">On Mar 31, 2015 2:10 PM, "Colin Riley" <<a href="mailto:colin@codeplay.com" target="_blank">colin@codeplay.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>I noticed that use in cmake also. FWIW,
my primary LLDB platform is Windows, which is why we were using
TinyXML2 for ease of prototyping. If libxml2 works on all the
targets we will use it - I do worry about the usual issues you get
with windows prebuilts. So source may still be required. We'll
look into it.<br>
<br>
Colin<br>
<br>
On 31/03/2015 20:45, Zachary Turner wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">There's already some stuff in the CMake to try to
find libxml, but it's behind a Darwin specific branch in the
CMake. So I think what would need to happen is that we move
this into a platform agnostic codepath, and then set a define
like LLDB_HAVE_LIBXML2 in the code to a value that indicates
whether it is present (search clang for CLANG_HAVE_LIBXML in *.*
to see how this is done). Then, in the code, we would need to
put xml code behind a check for this define.<br>
</div>
<br>
<div class="gmail_quote">On Tue, Mar 31, 2015 at 10:02 AM Zachary
Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">A good rule of thumb for anything is that
"Windows doesn't have it" and that holds true for libxml2 as
well. It appears that libxml2 does support Windows though (<a href="http://xmlsoft.org/downloads.html" target="_blank">http://xmlsoft.org/downloads.html</a>),
it just isn't something that's there by default. It would
be nice if everyone were using the same thing, could we
clone this repo in our own repo and then just build it
ourselves as part of the build process. The license looks
very permissive, but IANAL.<br>
</div>
<br>
<div class="gmail_quote">On Tue, Mar 31, 2015 at 9:47 AM Greg
Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Mar 31, 2015, at 3:35 AM, Aidan Dodds <<a href="mailto:aidan@codeplay.com" target="_blank">aidan@codeplay.com</a>> wrote:<br>
><br>
> On 30/03/2015 18:38, Greg Clayton wrote:<br>
> ><br>
> > I know about the register numbering stuff and I
would love to see support for the "$qXfer:features:" added
to LLDB. The one thing this data doesn't contain is the
register numbers for the ABI (DWARF register numbers (for
debug info), compiler register numbers (for like
.eh_frame)), but that info could be inferred from an ABI
plugin that we could infer from the "osabi" of "GNU/Linux"
in the target.xml:<br>
><br>
> ><br>
> > So please do submit patches that implement this
and we will be happy to approve them.<br>
><br>
> I am currently prototyping $qXfer:features support in
LLDB with an aim to upstream it. It will require an XML
parser, so I wanted to have a discussion about adding one
to LLDB.<br>
<br>
Most unix variants have libxml2 that is available. I am
not sure on windows though. I have CC'ed Zachary to get
some input on windows XML (in case LLVM doesn't already
have some support for this).<br>
<br>
> I have been using TinyXML2 in my prototype, which is
open sourced under the ZLib license. Is there any policy
in LLDB for handling external library dependencies?<br>
> Would there be objections to TinyXML2 making its way
into the LLDB code base as an external? Writing a new XML
parser from scratch in LLDB isn't ideal.<br>
<br>
It would be great to stick with stuff that everyone has
installed and hopefully that is libxml2. Windows is the
biggest question. I am also not sure if llvm or clang has
any XML support, but we should first look to see if llvm
has XML support and if not, then look for alternatives. We
definitely do not want to write our own.<br>
><br>
> I would still like to have a discussion about adding
a plugin architecture to gdb-remote making it easier to
handle packets outwith the LLDB based servers. The code in
gdb-remote that sends and handles packets is scattered
over one or two huge classes, it would be beneficial to
start looking at breaking this up and modularizing it. At
least for the packets which are not supported by lldb's
own RSP producers.<br>
<br>
I say just build all and any support it into
GDBRemoteCommunicationClient and
GDBRemoteCommunicationServer. I don't see the need to
break it up.<br>
<br>
Greg Clayton</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
lldb-dev mailing list
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div>
______________________________<u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>