[lldb-dev] swig generation

[Todd Fiala via lldb-dev]

On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner <zturner at google.com> wrote:

> 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.
>
>
I may leave Greg to discuss that aspect (w/r/t using newer features).  The
SB API itself is intended to be a very bare-bones linkage environment that
does not break linkage requirements in ways that typical C++ binary
libraries do (i.e. it does not use virtuals and follows a number of rules
about data members so that it remains binary compatible across
compiler/linker changes).


>
>
>>
>> * 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.
>
>

Haha that's exactly how I feel :-)


>
>> 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.
>
>


-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151113/09644859/attachment-0001.html>