We have a build option to build LLDB without Python. This option is automatically set if Cmake can’t find or “validate” your Python distribution.
Since LLDB is rarely built with this option, nobody discovers when this configuration breaks. For example, if you try it today, you’ll get a handful of missing symbol errors because their declarations are #if’ed out but other code still references them.
I’m proposing eliminating this option and fixing the validation of the Python distribution in LLDBConfig.cmake.
If you believe LLDB_DISABLE_PYTHON is still useful, please speak up, and I’ll instead look at fixing the existing build problems.
Even though you can just use debugserver/lldb-server and debug remotely, many people find it handy to be able to run a debugger directly on the device they are using. But requiring that you port Python and bundle it with your embedded platform just to get a debugger there is a pretty big ask. So it is still quite useful to be able to build lldb without Python. This option hasn't been broken all that frequently in our uses, but if it is being a problem, the better solution would be to set up a bot to build with this option, so we can make sure it keeps working.
I'm in favor of this. FWIW, I will be surprised if lldb works at all
with that option.
I think part of the problem is that we have APIs that are #ifdef PYTHON even though there seemingly isn't a good reason for it. For example, I have no idea why `GetSummaryForType` should be #ifdef PYTHON. I assume that has something to do with the fact that python can be one source of type summaries, but that doesn't mean the API itself needs to be disabled, particularly as we can (and do) write type summary providers in C.
I think that a more worthwhile effort would be to try to cut down on the amount of #ifdefed code without actually removing the ability to not use python at all.
That’s true, but there’s a maintenance burden associated with this handiness, and if nobody uses it that much (or at all?), it’s better IMO to optimize for low maintenance. Every time I’ve tried this configuration it has been broken, which leads me to believe that in practice nobody is actually using it. If that really is the case, I’d rather it be gone. I don’t think we should keep code around just in case, without specific evidence that it’s providing value.
I would actually be also surprised if it works. However, the option I think is important to keep is to be able to build lldb-server without python around. Nobody uses the lldb client on android (in fact, I'm pretty sure it doesn't work), but lldb-server is used there. Getting a working python for android is hard, and it seems counterproductive to ask somebody to do it, when lldb-server does not even use python.
If we can factor the code in such a way that code requiring python is not built/used when building lldb-server, then making python support mandatory for the rest seems reasonable to me.
Does lldb-server for Android currently use this flag? I was under the impression it just linked against Python anyway.
I second this opinion and have really not much further to add, except maybe that just yesterday to my delight I actually discovered this option and now promptly use it as the default when building my debugger variant. It removed a lot of python warnings when running my handbuilt lldb on macos.
No, it doesn't link against python. In fact, when targetting android, we default to disabling all external dependencies. LLDBConfig.cmake:
elseif(CMAKE_SYSTEM_NAME MATCHES "Android")
It does get used, though we might be able to get away from that at some point. But I still think requiring any new platform that might want to run a debugger to get Python up first is unfortunate, and we shouldn't lightly require it.
But also, this isn't just about Python in particular. Everything in lldb that touches the script interpreter should be going through the abstract ScriptInterpreter class. The only place where the fact that the script interpreter happens to be Python should show up is in the ScriptInterpreterPython. So building without Python should be as simple as not building the ScriptInterpreterPython and not initializing that plugin. The maintenance burden for this option should be trivial. Something is broken that LLDB_DISABLE_PYTHON has gotten entangled deeper in lldb. I'd much prefer we fix that.
It would be really cool, for instance, if lldb could support a Python2 and a Python3 script interpreter to ease the transition for folks with lots of legacy Python 2 code (such folks exist). lldb was designed to support that sort of thing.
Or maybe at some point we should support some other new hotness language. I'm not sure it is good to bind ourselves inextricably to Python.
Yes, Pavel pointed out one specific case where it is used, and that case definitely needs to be supported.
We’ve talked in the past about fixing the layering in such a way that all Python related code is in ScriptInterpreterPython, but there’s definitely a non-trivial amount of work needed to make that possible. And I agree, if that were the case today, then you could just turn it off trivially.
OK, thanks all for the discussion.
I’ll try to fix the immediate problems (the build breakage and the Python detection). If I get more ambitious, I’ll make another proposal.