On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner <ztur...@google.com> wrote:
> On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <
> lldb-dev@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
