[lldb-dev] static swig bindings and xcode workspace

[Todd Fiala via lldb-dev]

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/2ff58460/attachment.html>