static swig bindings and xcode workspace

Has the xcode build been changed to use static bindings yet? 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. 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.

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

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?

Hi Zachary,

Hi Zachary,

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.

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.

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