On Wed, Dec 2, 2015 at 8:28 AM, Todd Fiala <todd.fi...@gmail.com> wrote:
> Hi Zachary, > > On Mon, Nov 30, 2015 at 9:23 AM, Zachary Turner <ztur...@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
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
