r252764 changes finishSwigPythonLLDB.py to symlink the “six” module in site-packages. six.py is a symlink to /tools/lldb/third_party/Python/module/six/six.py. This assumes I have access to this build’s sources when I run lldb, which I don’t – our workstations don’t have access to the buildbots’ filesystem, and even if they did, the sources may change between build and run.
Shouldn’t six.py just be copied? It’s only 30k.
Zach, how do I do a build using static swig bindings? I don’t think we’re going to change the bindings internally, so using the standard ones should be fine.
What about requiring that the user has done “pip install six” on their machine?
Unfortunately, the LLDB we build needs to run on SLES 11, Ubuntu 10+ and who knows what else. I don’t think I can require they install a six package. I can make our build do a copy instead of a link, if you want to keep it a link.
Are the static swig bindings checked in yet, or do we still need to run swig to generate them on each build?
I don’t mind it being a copy instead of a link, I had just been thinking about getting rid of that workflow anyway and requiring a pip install. But if you can’t do that, then scratch that idea.
Feel free to change it to a copy and upstream that if it makes your life easier.
Just to be clear though, the issue with six is orthogonal to the issue with static bindings, right? We couldn’t all agree on a way to get static bindings in, so as of now it’s not a thing. I did some work to get a swig-as-a-service thing going, and it’s mostly complete except for the part where I get a server and make it run on that server. If I can push that through static bindings will be a thing again, but I’m blocked on that for the moment.