[llvm-dev] HTTP library in LLVM

Petr Hosek via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 31 17:21:50 PDT 2020


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 <jonas at devlieghere.com>
wrote:

> On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev <
> llvm-dev at 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 <echristo at gmail.com>
>> wrote:
>>
>>> +LLDB Dev <lldb-dev at lists.llvm.org> as well for visibility. +Pavel
>>> Labath <labath at google.com> since he and I have talked about such things.
>>>
>>> On Mon, Aug 31, 2020 at 7:26 PM David Blaikie <dblaikie at gmail.com>
>>> 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-dev at 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-dev at lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200831/068f7618/attachment-0001.html>


More information about the llvm-dev mailing list