I was referring to the Swift and Apple internal branches. They tend to lock down against older llvm and clang repositories so when we put changes in llvm or clang that are required for LLDB, it makes merging a bit tougher in those cases. Again, I am not affected by this, just trying to watch out for you guys.
Greg > On May 8, 2018, at 11:35 AM, Greg Clayton <clayb...@gmail.com> wrote: > > I'm good if Apple is good. > >> On May 8, 2018, at 11:31 AM, Frédéric Riss <fr...@apple.com >> <mailto:fr...@apple.com>> wrote: >> >> >> >>> On May 8, 2018, at 10:04 AM, Greg Clayton via lldb-dev >>> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: >>> >>> >>> >>>> On May 8, 2018, at 9:47 AM, Zachary Turner <ztur...@google.com >>>> <mailto:ztur...@google.com>> wrote: >>>> >>>> We don’t want the lowest levels of lldb to depend on clang. If this is >>>> useful we should move it from clang to llvm and use llvm::VersionTuple >>> >>> I agree, though this move will cause merging issues for many that have >>> repositories that link against older llvm/clang. Doesn't affect me anymore, >>> but Apple will be affected. >> >> I’m not sure I understand what issues you’re referring to, we don’t link new >> LLDBs to old clangs (and even if we did, it wouldn’t be something the that >> drives community decisions). >> >> Fred >> >>> Greg >>> >>>> On Tue, May 8, 2018 at 9:26 AM Greg Clayton via lldb-dev >>>> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: >>>> No issues from me. >>>> >>>> > On May 8, 2018, at 9:11 AM, Pavel Labath via lldb-dev >>>> > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: >>>> > >>>> > While moving Args around, I noticed that we have a bunch of >>>> > functions/classes that pass/store version numbers as a triplet of >>>> > integers >>>> > (e.g. Platform::GetOSVersion). I got halfway into creating a wrapper >>>> > class >>>> > for that when I noticed clang::VersionTuple, which is pretty much what I >>>> > wanted out of the box. >>>> > >>>> > Now there are small differences between this class, and what we have now: >>>> > it has an extra fourth "build" field, and it uses only 31 bits to >>>> > represent >>>> > the values. None of these seem to matter (particularly as we are >>>> > converting our representation into this struct in some places) that much, >>>> > but before I go through the trouble of pulling this class into llvm >>>> > (although technically possible, it seems wrong to pull a clang dependency >>>> > at such a low level), I wanted to make sure we are able to use it. >>>> > >>>> > Do you see any reason why we could not replace our version triplets with >>>> > clang::VersionTuple ? >>>> > >>>> > cheers, >>>> > pl >>>> > _______________________________________________ >>>> > lldb-dev mailing list >>>> > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>> > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >>>> >>>> _______________________________________________ >>>> lldb-dev mailing list >>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
