<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Agreed that better layering and modularization is a worthwhile longer-term goal. These kinds of changes should be researched and proposed for discussion because code reorganization can be extremely disruptive (which is why we opened this comment period for the proposed reformatting!) I’d generally argue for focusing on breaking out larger blocks of functionality where focused testing will yield results rather than a lot of fine-grained change.<div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="" style="font-family: LucidaGrande; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><font color="#424242" class="" style="font-family: 'Lucida Grande'; font-size: x-small;">Kate Stone</font><span class="" style="font-family: 'Lucida Grande'; font-size: x-small;"> </span><font color="#009193" class="" style="font-family: 'Lucida Grande'; font-size: x-small;"><a href="mailto:k8stone@apple.com" class="">k8stone@apple.com</a></font></div><div class="" style="font-family: Times; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><font face="Lucida Grande" size="1" class=""><font color="#009193" class=""></font> Xcode <font color="#424242" class="">Low Level Tools</font></font></div></div></div></div></div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Aug 9, 2016, at 11:10 AM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Another thing worth thinking about for the long term is library layering and breaking the massive dependency cycle in LLDB. Every library currently depends on every other library. This isn't good for build times, code size, or reusability (especially where size matters like in lldb-server). I think the massive Python dependency was removed after my work earlier this year. But I'm not sure what the status of that is now, and there's still the rest of LLDB.<div class=""><br class=""></div><div class="">In the future it would be nice to have a modules build of LLDB. And sure, we could just have liblldb be one giant module, but that seems to kind of defeat the purpose of modules in the first place.</div><div class=""><br class=""></div><div class="">For unit tests in particular, it's nice to be able to link in just the set of things you need, and that's difficult / impossible right now.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Aug 9, 2016 at 10:00 AM Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a>> wrote:<br class=""></div></div></div><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div style="font-family:HelveticaNeue" class=""><div class=""><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""><br class=""></div></blockquote><div class=""></div></div></div><div style="font-family:HelveticaNeue" class=""><div class=""><b class="">Near-Term Goal: Standardizing on LLVM-style clang-format Rules</b></div><div class=""><br class=""></div><div class="">We’ve heard from several in the community that would prefer to have a single code formatting style to further unify the two code bases. Using clang-format with the default LLVM conventions would simplify code migration, editor configuration, and coding habits for developers who work in multiple LLVM projects. There are non-trivial implications to reformatting a code base with this much history. It can obfuscate history and impact downstream projects by complicating merges. Ideally, it should be done once with as much advance notice as is practical. Here’s the timeline we’re proposing:</div><div class=""><br class=""></div><div class=""><b class="">Today</b> - mechanical reformatting proposed, comment period begins</div><div class=""><br class=""></div></div><blockquote style="font-family:HelveticaNeue;margin:0px 0px 0px 40px;border:none;padding:0px" class="">To get a preview of what straightforward reformatting of the code looks like, just follow these steps to get a clean copy of the repository and reformat it:</blockquote><blockquote style="font-family:HelveticaNeue;margin:0px 0px 0px 40px;border:none;padding:0px" class=""><ol class=""><li class="">Check out a clean copy of the existing repository</li><li class="">Edit .clang-format in the root of the tree, remove all but the line “BasedOnStyle: LLVM”</li><li class="">Change your current working directory to the root of the tree to reformat</li><li class="">Double-check to make sure you did step 3 ;-)</li><li class="">Run the following shell command: "find . -name "*.[c,cpp,h] -exec clang-format -i {} +"</li></ol></blockquote><br style="font-family:HelveticaNeue" class=""><div style="font-family:HelveticaNeue" class=""><div class=""><b class="">Aug 20th</b> - comment period closes, final schedule proposed</div><div class=""><b class="">TBD (early September?)</b> - patches land in svn</div><div class=""><br class=""></div><div class="">The purpose of the comment period is to review the straightforward diffs to identify areas where comment pragmas should be used to avoid undesirable formatting (tables laid out in code are a classic example.) It’s also a time when feedback on the final timetable can be discussed, and any unforeseen implications can be discovered. We understand that LLDB tends toward relatively long names that may not always work well with the LLVM convention of wrapping at 80 columns. Worst case scenarios will be evaluated to determine the desired course of action.</div></div></div></blockquote><div class=""><br class=""></div></div></div><div dir="ltr" class=""><div class="gmail_quote"><div class="">One thing we will need to take a look at is functions which have a very deep indentation level. <span style="line-height:1.5" class="">They have the potential to be made really ugly by clang-format. The default indentation will be reduced from 4 to 2, so that will help, but I recall we had some lines that began very far to the right. </span></div><div class=""><br class=""></div><div class="">Here's a little bash command shows all lines with >= 50 leading spaces, sorted in descending order by number of leading spaces.</div><div class=""><br class=""></div><div class="">grep -n '^ \+' . -r -o | awk '{t=length($0);sub(" *$","");printf("%s%d\n", $0, t-length($0));}' | sort -t: -n -k 3 -r | awk 'BEGIN { FS = ":" } ; { if ($3 >= 50) print $0 }' </div><div class=""><br class=""></div><div class="">It's less useful than I was hoping because most of the lines are noise (line breaking in a function parameter list).</div><div class=""><br class=""></div><div class="">If there were a way to detect indentation level that would be better. Mostly just to identify places that we should manually inspect after running clang-format.</div></div></div></blockquote></div>
_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></div></blockquote></div><br class=""></div></body></html>