[lldb-dev] static swig bindings and xcode workspace

[Zachary Turner via lldb-dev]

Ahh, that's a bummer if true.  Because `contrib` is a nice way to group
together all the things that all the things that have specific maintainers
and so everyone else is allowed to break.

On Wed, Dec 2, 2015 at 11:04 AM Todd Fiala <todd.fiala at gmail.com> wrote:

> On Wed, Dec 2, 2015 at 8:28 AM, Todd Fiala <todd.fiala at gmail.com> wrote:
>
>> Hi Zachary,
>>
>> On Mon, Nov 30, 2015 at 9:23 AM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> Has the xcode build been changed to use static bindings yet?
>>>
>>
>> It is only in our downstream branches.  I stripped out support in
>> llvm.org lldb per our other threads.
>>
>>
>>>   I got to thinking that maybe it would make sense to put them alongside
>>> the xcode workspace folders, just to emphasize that the static bindings
>>> were an artifact of how the xcode build works.
>>>
>>
>> We could do that.  Internally we also use that for builds other than
>> Xcode, so whatever solution I use (which is currently what I had proposed
>> earlier but now have only in our branches) really needs to work for more
>> than Xcode.
>>
>>
>>>   This way we just say "Xcode build uses static bindings" and "CMake
>>> build needs an installed swig", and this is enforced at the directory
>>> level.
>>>
>>>
>> That's a great compromise, I appreciate your thoughts on that.  Since I
>> need it for more than Xcode, right now the solution I have in our branch is
>> working okay.
>>
>>
>>> In order to do this you'd have to probably make a new toplevel folder to
>>> house both the lldb.xcodeproj and lldb.xcworkspace folders, but I think
>>> that would be useful for other reasons as well.  For example, I want to
>>> check in a visual studio python solution for the test suite at some point,
>>> and it would make sense if all of this additional stuff was in one place.
>>> So perhaps something like:
>>>
>>> lldb
>>> |__ contrib
>>>     |__ xcode
>>>         |__ LLDBWrapPython.cpp
>>>         |__ lldb.py
>>>         |__ lldb.xcodeproj
>>>         |__ lldb.xcworkspace
>>>     |__ msvc
>>>
>>>
>> That structure may make sense.  That could live in llvm.org.  Then for
>> other OSes where I want similar behavior, I could just keep those parts in
>> our branch.  Ultimately I'd end up with multiple copies of the wrapper (for
>> any OS we may build for internally), but I could symlink so that's not
>> really any kind of issue.
>>
>> This might work.
>>
>>
>>> I have been thinking about this idea of a contrib folder for a while
>>> anyway, but wanted to have more reasons to make use of it before I brought
>>> it up.
>>>
>>> Good idea?  Bad idea?  Thoughts?
>>>
>>
>> I could see that layout making sense.  If we did something like that, I
>> think I'd separate moving the lldb.xcodeproj and lldb.xcworkspace from the
>> creation of the contrib folder.
>>
>
> It looks like we may have some reasons why we need the Xcode
> workspace/project files at the top of the lldb source tree.  I'm not sure
> we'll able to move those.  But the rest of it looks like a reasonable way
> to go.
>
>
>>  (i.e. I'd start with the wrapper part in there, and have the others move
>> there at lower priority as a scheduling thing --- there's a bit of work to
>> make the workspace/project change but should be totally doable).
>>
>> I think I like the idea since it reduces the number of merge issues I'd
>> have to deal with.
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151202/2f357fae/attachment.html>