[lldb-dev] swig generation

[Zachary Turner via lldb-dev]

On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> 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).
>
I know you said you plan to stay on 1.x, but in this world of having SWIG
bindings checked in, does that open the door to potentially moving beyond
SWIG 1.x for the upstream?  I feel like the SWIG 1.x requirement holds the
upstream back, because there are a lot of hacks to workaround bugs and
limitations in SWIG, and it only understands the absolute most basic C /
C++ language constructs.  So we end up being limited in how we can design
SB APIs, all for reasons that having nothing to do with the upstream
project requirements, which is kind of a bummer.  It seems like there could
be a path here for the upstream to move forward, and anyone who is forced
to stay on an earlier version of SWIG could maintain whatever changes are
necessary to make this possible in a local repository.



>
> * 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.
>
Ugh, +1000.  Every time I have to crack these files open my head explodes.
More than happy to help with whatever porting is necessary.


>
> 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.
>
Yay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151113/cfd123c5/attachment.html>