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.
On Tue, Mar 31, 2015 at 4:36 PM Vince Harron <vi...@nethacker.com> wrote: > 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 . > On Mar 31, 2015 4:28 PM, "Zachary Turner" <ztur...@google.com> wrote: > >> 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. >> >> On Tue, Mar 31, 2015 at 4:19 PM Vince Harron <vi...@nethacker.com> wrote: >> >>> 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. >>> On Mar 31, 2015 2:10 PM, "Colin Riley" <co...@codeplay.com> wrote: >>> >>>> 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. >>>> >>>> Colin >>>> >>>> On 31/03/2015 20:45, Zachary Turner wrote: >>>> >>>> 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. >>>> >>>> On Tue, Mar 31, 2015 at 10:02 AM Zachary Turner <ztur...@google.com> >>>> wrote: >>>> >>>>> 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 (http://xmlsoft.org/downloads.html), 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. >>>>> >>>>> On Tue, Mar 31, 2015 at 9:47 AM Greg Clayton <gclay...@apple.com> >>>>> wrote: >>>>> >>>>>> >>>>>> > On Mar 31, 2015, at 3:35 AM, Aidan Dodds <ai...@codeplay.com> >>>>>> wrote: >>>>>> > >>>>>> > On 30/03/2015 18:38, Greg Clayton wrote: >>>>>> > > >>>>>> > > 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: >>>>>> > >>>>>> > > >>>>>> > > So please do submit patches that implement this and we will be >>>>>> happy to approve them. >>>>>> > >>>>>> > 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. >>>>>> >>>>>> 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). >>>>>> >>>>>> > 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? >>>>>> > 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. >>>>>> >>>>>> 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. >>>>>> > >>>>>> > 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. >>>>>> >>>>>> I say just build all and any support it into >>>>>> GDBRemoteCommunicationClient and GDBRemoteCommunicationServer. I don't >>>>>> see >>>>>> the need to break it up. >>>>>> >>>>>> Greg Clayton >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> lldb-dev mailing >>>> listlldb-...@cs.uiuc.eduhttp://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 >>>> >>>> _______________________________________________ >>> 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
