labath added a comment.

In principle, I think this is a good idea. We do have many optional components 
(and even more components that should be optional but aren't), that one may not 
need/want when building lldb for a specific use case. Also, libLLVM is 
configurable in a similar way. However:

- as Raphael pointed out, this is incomplete. I'm not too worried about 
managing dependencies -- I'd consider this an expert feature, and I am happy 
with leaving it up to the user to ensure he does not disable a plugin that is 
used elsewhere (he should get a link error if he does). But that still leaves 
the question of how to register the plugins at startup. We currently have a 
hand-curated list of plugins in the SystemInitializer classes, and that will 
need to change somehow. This is further complicated by the fact that some 
plugins are also needed for lldb-server, while others (most) are used in 
liblldb only. The simplest solution (for usage, but maybe not for 
implementation) would be to have the plugins auto-register themselves via a 
global constructor. Some parts of llvm already to that, and we could create a 
special class for this which would also carry the annotations necessary to 
surpress the global constructor warnings. The alternative is to throw in a 
bunch of ifdefs into the SystemInitializers, which isn't particularly nice 
(though maybe it could be generated in cmake or via some `.def` tricks).
- there will also be a need to somehow disable the tests for the relevant 
plugins. For instance all the NativePDB tests will fail when disabling that 
plugin (even on darwin, as the tests are written in a way to not require a 
windows host). I don't think we need to annotate all tests with the exact list 
of plugins that the require (that can be up to whoever wants to ensure that 
some configuration keeps working), but we should create some mechanism to do 
that.
- I also wouldn't advertise this too much. Using these settings can easily send 
someone into uncharted waters, with random unexpected build errors or test 
failures -- we have enough of those even without new settings. And unlike 
LLVM_TARGETS_TO_BUILD, I doubt disabling some plugins will have measurable 
impact on the build time...


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D73016



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to