[PATCH] D112758: [llvm] [Debuginfo] Debuginfod client library.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 23 12:16:59 PST 2021


dblaikie added inline comments.


================
Comment at: llvm/lib/Debuginfod/CMakeLists.txt:1
+if(LLVM_ENABLE_CURL)
+  add_llvm_component_library(LLVMDebuginfod
----------------
labath wrote:
> dblaikie wrote:
> > noajshu wrote:
> > > dblaikie wrote:
> > > > labath wrote:
> > > > > This may be the first case, where the very existence of a component library is predicated on the availability of a third party dep. That's not necessarily a bad thing (it'd also be strange to enable it when it is completely non-functional), but it did catch my eye.
> > > > Yeah, I had mixed feelings about this with the machine learning - if the API is going to always be exposed, maybe the API should be in the library, and it gets compiled into a trivially uninteresting library that always fails the query - rather than having the entry point outside the library, and having that entry point not call into the library if it isn't available/couldn't do something real?
> > > It should work this way right now. When built without curl, the debuginfod client will still be able to retrieve artifacts from the local cache.
> > Hmm, I guess I'm not sure what @labath was referring to with "existence of a component library is predicated on the availability of a third party dep" - perhaps the comment is out of date? Which component library did you have in mind, @labath?
> This component. In the earlier versions of this patch the entire file was wrapped in `if(LLVM_ENABLE_CURL)`.
Ah, OK!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112758/new/

https://reviews.llvm.org/D112758



More information about the llvm-commits mailing list