Hi all,
I’d like to do a few things with our swig generation and handling:
- Create a maintainer-mode style setup where the swig Python bindings are generated and checked into the repo (I’ll call it the static python binding).
This will be used by default, removing the need for most people and all builders/bots from having swig on their system just for lldb. In the event that Windows needs a different version (e.g. for, say, Python 3.5 support that is incompatible with the swig-1.3.40-generated bindings), we can support multiple source bindings, or we can post process the swig-1.3.x generated bindings.
We’ll keep them by swig-{swig-major}-{swig-minor}. Internally over at Apple, we will stick with the swig-1.x bindings. I don’t think we will care about the dot release (1.3.40 vs. 1.3.39, for example). We’ll just make sure to use the latest for a {swig-major}.{swig-minor}. As always, SB API changes generated by swig need to remain swig-1.3 compatible (i.e. swig-1.3 must be capable of generating usable Python wrappers).
Ideally we don’t need more than one set of bindings so we can avoid needing to generate multiple ones when we do it.
- Add an explicit Python binding generation step.
This would only be used by those who are touching the bindings (adding SB API or adjusting the documentation of existing SB API). In the event that we need two bindings, we may just need a handshake that says “okay, we’ll take care of the swig 1.3 bindings, and {somebody who needs the other binding} generates it for the other.” As SBAPI is additive only, this should generally be fine as the worst case I can think of that would happen would be failure to see new SBAPI in Python for a very brief time. Since maintainers will be writing Python tests to check their new SBAPIs, failure to do the explicit generation step will be immediately obvious as a test failure. (The challenge here will likely be the swig 1.3.x requirement).
If generating and testing new binding content with the right swig (i.e. swig 1.3.x) becomes a real issue, we may be able to support a "please use my local swig, whatever it is, but don’t check in the static binding), with a handshake that says "somebody with swig 1.3, please generate the modified binding and check in). We’ll see if this becomes an issue. I don’t see this as insurmountable.
- Clean up the swig generation scripts
These look to have been implemented as direct ports of the older OS X style bash scripts. This Python script is very much the essence of using the paradigms of one language in another, and being the worse for it. It implements features that are already present in the standard Python lib, and is more verbose than it needs to be.
Also, it is likely the script needs to be broken out into a few parts. The scripts don’t just generate the python binding using swig, they also setup (for OS X) some packaging and other bits. Right now none of that is clearly broken out. When we move to an explicit binding generation mode, this does need to be broken out better.
- Get OS X Xcode build using the same bindings machinery as others.
I tried this a while back (having Xcode adopt the Python-based swig wrapper handling code), but gave up after hitting a few bugs where the translated behavior was incorrect for Xcode. I will move over to adopting this on Xcode if possible while going through these changes.
The primary goal here is to remove the requirement of having swig on the system (e.g. for builders and most developers), shifting that burden a bit more to those who actually modify the Python binding.
As a potential added benefit, this opens us up to easier modification of that binding generation step, which may prove to be useful later.
Let me know if you have any feedback before I dive into this.
