JDevlieghere wrote: > This was what we were doing in the [initial > PR](https://github.com/llvm/llvm-project/pull/98528/files#diff-20a2060f8e87c6742d6f2c7ae97e919f8485995d7808bd9fccbfbede697a9ec7) > but Pavel had correctly pointed out that the architecture was unnecessarily > "baroque". GIven there will be only one instance of the TelemetrManager at a > time and that we will not be creating a new manager on the fly, none of those > complex hooks are necessary. > > Instead, we just need the downstream implemntation to register its instance > (via the setInstance()). Then the rest of (upstream) LLDB code, which uses > the Telemetry, would just do `TelemetryManager::getInstance()`.
Thanks for the clarification. I had a feeling I had missed something. But then I don't get the point of making it a "plugin" at all. What's the benefit of declaring it as a plugin. As much as I agree that the plugin system is _baroque_, there is value in consistency and everything that's called a plugin working the same way. Me being surprised by the PR is a concrete example of that. More of a question for @labath but do we have an example of another place where we have "semi plugins" like this and if not, what are existing plugins that could be reworked to be lighter weight? I think we need to have a sufficiently strong motivation to diverge from the existing way of writing plugins (or have a renaissance where we improve it for all the plugins). https://github.com/llvm/llvm-project/pull/126588 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
