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 <ztur...@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.fi...@gmail.com> wrote: > >> 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 >> > -- -Todd
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
