charles-zablit wrote: > That's not really what I had in mind in my last comment. I wanted to move the > logic from the InitializePythonRAII constructor onto a method that could > return an `llvm::Error` (apologies for the typo in my last comment) to > propagate the error cleanly, not call `llvm::report_fatal_error` which would > cause us to abort. > > I can see how in the current design this wouldn't be possible since this is > called when the ScriptInterpreterPython is initialized, which is at launch > ... that's why I thinking may be we could make the scripted interpreter > initialization lazy: we wouldn't call Initialize until the user runs the > `script` command or loads a scripting resource, so the user can still use > lldb **without** python support. This doesn't have to be done as part of this > PR but I'm wondering that'd help out with your problem. > > cc. @JDevlieghere
I agree that we should make the initialization lazy. This would help greatly with the initial problem I was trying to solve. More generally, I also think that we should have a generic mechanism to "allow" plugins to fail when they initialize, or at least have the `Initialize` return `llvm::Error` rather than `void` to report errors during initialization. I don't know if that has been attempted before. https://github.com/llvm/llvm-project/pull/181160 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
