[Lldb-commits] [lldb] [llvm] Reland "[Support] Move HTTP client/server to new LLVMSupportHTTP lib (NFC)" (PR #185410)

[Stefan Gränitz via lldb-commits]

================
@@ -0,0 +1,20 @@
+# Link LibCURL if the user wants it
+if (LLVM_ENABLE_CURL)
+  set(imported_libs CURL::libcurl)
+endif()
+
+# Link cpp-httplib if the user wants it
+if (LLVM_ENABLE_HTTPLIB)
+  set(imported_libs ${imported_libs} httplib::httplib)
+endif()
+
+add_llvm_library(LLVMSupportHTTP
+  HTTPClient.cpp
+  HTTPServer.cpp
+
+  LINK_LIBS
+  ${imported_libs}
+
+  LINK_COMPONENTS
+  Support
+)
----------------
weliveindetail wrote:

Problem with my proposal is that we have no independent HTTP client tests and we need a server to implement them. That's not different than today, where all test coverage for `HTTPClient` is in `unittests/Debuginfod/HTTPClientServerTest.cpp`.

If we had a LIT test, we could use Python's `http.server` to test `HTTPClient`, but I don't  think we want to add a tool just to provide access here and going through `llvm-debuginfod`/`llvm-debuginfod-find` is not suitable to test LLVMSupport.

So, coming back to your original question: Could we split this into a client and a server library? In principle yes, we could add two libs `LLVMSupportHTTPClient` and `LLVMSupportHTTPServer`. Most tools would depend only on `LLVMSupportHTTPClient`, which saves some build time and avoids thinking about `LLVM_ENABLE_HTTPLIB` (which enables the server). I am not sure though, if that's worth adding another lib and the dependency management overhead that come with it.

I'd tend towards no. What do you think? Any other ideas?

https://github.com/llvm/llvm-project/pull/185410