[lldb-dev] static swig bindings and xcode workspace
Todd Fiala via lldb-dev
lldb-dev at lists.llvm.org
Wed Dec 2 08:28:11 PST 2015
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
> 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:
> |__ 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. (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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev