Re: [lldb-dev] [llvm-dev] HTTP library in LLVM
+LLDB Dev as well for visibility. +Pavel Labath since he and I have talked about such things. On Mon, Aug 31, 2020 at 7:26 PM David Blaikie wrote: > [+debug info folks, just as FYI - since the immediate question's more > about 3rd party library deps than the nuances of DWARF, etc] > > I'd imagine avoiding writing such a thing from scratch would be desirable, > but that the decision might depend somewhat on what libraries out there > you/we would consider including, what their licenses and further > dependencies are. > > On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> We're considering implementing [debuginfod]( >> https://sourceware.org/elfutils/Debuginfod.html) library in LLVM. >> Initially, we'd like to start with the client implementation, which would >> enable debuginfod support in tools like llvm-symbolizer, but later we'd >> also like to provide LLVM-based debuginfod server implementation. >> >> debuginfod uses HTTP and so we need an HTTP library, ideally one that >> supports both client and server. >> >> The question is, would it be acceptable to use an existing C++ HTTP >> library or would it be preferred to implement an HTTP library in LLVM from >> scratch? >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] HTTP library in LLVM
On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek wrote: > There are several options, I've looked at couple of them and the one I > like the most so far is https://github.com/yhirose/cpp-httplib for a few > reasons: > > * It's MIT licensed. > I hesitate to get into it on the list, not-a-lawyer, etc. But does that seem like it'd be as usable as other code we have (zlib, gtest, etc) used by/in LLVM? > * It supports Linux, macOS and Windows (and presumably other platforms). > * It doesn't have any dependencies, it can optionally use zlib and OpenSSL. > * It's a modern C++11 implementation, the entire library is a single > header. > Handy - I guess you'd want to check that in (ala gtest, rather than ala zlib which is used from the system) to the llvm-project repository, then? > > On Mon, Aug 31, 2020 at 4:31 PM Eric Christopher > wrote: > >> +LLDB Dev as well for visibility. +Pavel Labath >> since he and I have talked about such things. >> >> On Mon, Aug 31, 2020 at 7:26 PM David Blaikie wrote: >> >>> [+debug info folks, just as FYI - since the immediate question's more >>> about 3rd party library deps than the nuances of DWARF, etc] >>> >>> I'd imagine avoiding writing such a thing from scratch would be >>> desirable, but that the decision might depend somewhat on what libraries >>> out there you/we would consider including, what their licenses and further >>> dependencies are. >>> >>> On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev < >>> llvm-...@lists.llvm.org> wrote: >>> We're considering implementing [debuginfod]( https://sourceware.org/elfutils/Debuginfod.html) library in LLVM. Initially, we'd like to start with the client implementation, which would enable debuginfod support in tools like llvm-symbolizer, but later we'd also like to provide LLVM-based debuginfod server implementation. debuginfod uses HTTP and so we need an HTTP library, ideally one that supports both client and server. The question is, would it be acceptable to use an existing C++ HTTP library or would it be preferred to implement an HTTP library in LLVM from scratch? ___ LLVM Developers mailing list llvm-...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] HTTP library in LLVM
On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev < llvm-...@lists.llvm.org> wrote: > There are several options, I've looked at couple of them and the one I > like the most so far is https://github.com/yhirose/cpp-httplib for a few > reasons: > > * It's MIT licensed. > * It supports Linux, macOS and Windows (and presumably other platforms). > * It doesn't have any dependencies, it can optionally use zlib and OpenSSL. > * It's a modern C++11 implementation, the entire library is a single > header. > This looks appealing indeed. Out of curiosity, what are the other alternatives you considered? > > On Mon, Aug 31, 2020 at 4:31 PM Eric Christopher > wrote: > >> +LLDB Dev as well for visibility. +Pavel Labath >> since he and I have talked about such things. >> >> On Mon, Aug 31, 2020 at 7:26 PM David Blaikie wrote: >> >>> [+debug info folks, just as FYI - since the immediate question's more >>> about 3rd party library deps than the nuances of DWARF, etc] >>> >>> I'd imagine avoiding writing such a thing from scratch would be >>> desirable, but that the decision might depend somewhat on what libraries >>> out there you/we would consider including, what their licenses and further >>> dependencies are. >>> >>> On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev < >>> llvm-...@lists.llvm.org> wrote: >>> We're considering implementing [debuginfod]( https://sourceware.org/elfutils/Debuginfod.html) library in LLVM. Initially, we'd like to start with the client implementation, which would enable debuginfod support in tools like llvm-symbolizer, but later we'd also like to provide LLVM-based debuginfod server implementation. debuginfod uses HTTP and so we need an HTTP library, ideally one that supports both client and server. The question is, would it be acceptable to use an existing C++ HTTP library or would it be preferred to implement an HTTP library in LLVM from scratch? ___ LLVM Developers mailing list llvm-...@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] HTTP library in LLVM
These are the ones I found so far: * [libmicrohttpd](https://www.gnu.org/software/libmicrohttpd/) is used by elfutils' debuginfod, but it's LGPL licensed. * [libcURL](https://curl.haxx.se/libcurl/) would be an option for the client, but we'd need a different library for the server. * [libhttp](https://github.com/lammertb/libhttp) is another MIT licensed library that could be a fit, but it seems bigger and more featureful than httplib. * [cpprestsdk](https://github.com/microsoft/cpprestsdk) has a lot of extra features we don't need, like websockets. * [pistache](https://github.com/oktal/pistache) similarly has additional features and dependencies that are likely unnecessary. * [crow](https://github.com/ipkn/crow) is similar to cpprestsdk and pistache, it depends on Boost. * [cpp-netlib](https://github.com/cpp-netlib/cpp-netlib) looks nice but depends on Boost. * [proxygen](https://github.com/facebook/proxygen) is also nice but has a lot of dependencies including Boost. On Mon, Aug 31, 2020 at 4:48 PM Jonas Devlieghere wrote: > On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> There are several options, I've looked at couple of them and the one I >> like the most so far is https://github.com/yhirose/cpp-httplib for a few >> reasons: >> >> * It's MIT licensed. >> * It supports Linux, macOS and Windows (and presumably other platforms). >> * It doesn't have any dependencies, it can optionally use zlib and >> OpenSSL. >> * It's a modern C++11 implementation, the entire library is a single >> header. >> > > This looks appealing indeed. Out of curiosity, what are the other > alternatives you considered? > > >> >> On Mon, Aug 31, 2020 at 4:31 PM Eric Christopher >> wrote: >> >>> +LLDB Dev as well for visibility. +Pavel >>> Labath since he and I have talked about such things. >>> >>> On Mon, Aug 31, 2020 at 7:26 PM David Blaikie >>> wrote: >>> [+debug info folks, just as FYI - since the immediate question's more about 3rd party library deps than the nuances of DWARF, etc] I'd imagine avoiding writing such a thing from scratch would be desirable, but that the decision might depend somewhat on what libraries out there you/we would consider including, what their licenses and further dependencies are. On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev < llvm-...@lists.llvm.org> wrote: > We're considering implementing [debuginfod]( > https://sourceware.org/elfutils/Debuginfod.html) library in LLVM. > Initially, we'd like to start with the client implementation, which would > enable debuginfod support in tools like llvm-symbolizer, but later we'd > also like to provide LLVM-based debuginfod server implementation. > > debuginfod uses HTTP and so we need an HTTP library, ideally one that > supports both client and server. > > The question is, would it be acceptable to use an existing C++ HTTP > library or would it be preferred to implement an HTTP library in LLVM from > scratch? > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
