[lldb-dev] static swig bindings and xcode workspace

[Todd Fiala via lldb-dev]

I'll dig in more when I get to it, but yeah I like the concept for sure.

On Wed, Dec 2, 2015 at 11:12 AM, Zachary Turner <zturner at google.com> wrote:

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


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