On Fri, Nov 13, 2015 at 10:24 AM, Todd Fiala <todd.fi...@gmail.com> wrote:
>
>
> 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,
>>
>
We do have the ability to post-process this any way we want after the swig
generation. I see no reason why we couldn't get move advanced with what we
post-process, especially since that can be limited to the
maintainer-mode-style "update the static checked-in product after
generating the bindings" step).
> 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
>
--
-Todd
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
