On 22/11/2019 01:26, Adrian McCarthy wrote:
Yes, that sounds plausible, but I don't recall for sure. I think
there's a build-time option to say you don't want Python at all, but I
can't remember if there was a load-as-needed option.
I'm pretty sure we have never had explicit support for anything like
this. The only way I can see this happening is if this fell out
"accidentally" out of our lazy python initialization and some windows
dll behavior, but I don't think windows has anything like that. (At
least on linux, I know that lazy binding can delay library mismatch
errors until the first time you call some function, but they won't help
you if the library is not there at all.)
I think the more likely scenario is that python was disabled in the
previous "official" releases, and that some of the python changes
enabled it.
In any event, the current situation is what it is. What's feasible and
worth doing for the future?
* Hard dependency (as we have right now)
I'm fine with that. We could add a note on the website that one needs to
have python installed for this to work. Or we could disable python for
the official releases.
* Dynamically load Python DLL on startup if it exists, or provide a
better error message with instructions
* Dynamically load Python DLL on startup if it exists, otherwise disable
Python-dependent features
* Dynamically load a specific version of the Python DLL if/when needed
All of these seem fine too, if anyone is willing to invest the time to
make it work (it shouldn't be _that_ hard). Since python is pretty
compartmentalized nowadays, it shouldn't relatively easy to disable
python features at runtime instead of just exiting.
The main question I have here is should we dlopen python.dll, or some
lldb wrapper of it (the entire "script interpreter" plugin).
I'd also like to note that this isn't the only external dependency of
lldb. (Well, it might be on windows..) Lldb can use libcurses, libedit,
libz, etc. Libedit is fairly likely to not be present on a random linux
system. libcurses are almost certainly there, but it's not always a
compatible version, etc.
* Dynamically load any supported Python DLL if/when needed
That might be tricky since the different versions are not binary
compatible in general. But it is possible, as Apple folks have shown,
though it amounts to building multiple copies of ScriptInterpreterPython
and then choosing the right one at runtime.
pl
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
