<div dir="ltr"><div dir="ltr"><div>On Fri, May 24, 2019 at 2:31 PM Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, 24 May 2019 at 09:57, Sam McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, May 24, 2019 at 6:28 PM Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, May 24, 2019 at 4:34 AM Ilya Biryukov <<a href="mailto:ibiryukov@google.com" target="_blank">ibiryukov@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>While I personally like consistent naming myself, I'd prefer to be conservative with this one and avoid changing something that is not broken for other reasons and was like this for years.</div></div></blockquote><div><br></div><div>I find this kind of argument not very convincing. See e.g. the first 7 slides of <a href="https://www.usenix.org/sites/default/files/conference/protected-files/srecon17americas_slides_reese.pdf" target="_blank">https://www.usenix.org/sites/default/files/conference/protected-files/srecon17americas_slides_reese.pdf</a></div><div><br>We've renamed many libraries to increase consistency, and we know from experience it's a pretty safe thing to do.</div></div></div></blockquote><div>I've dealt with the fallout from one of these renames recently - we silently lost some changes during a (non-git, non-svn) merge.</div><div>The unsafeness of it may not be visible from upstream LLVM :-)</div></div></div></blockquote><div><br></div><div>I agree. That said, the fact that we accept upstream churn without regard to out-of-tree users (even when those users are ourselves!) is a forcing function that we use to encourage people to upstream their changes. It's unsustainable to hold back upstream cleanups in order to make it easier to maintain out-of-tree patches.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>If we do rename, do folks prefer:</div><div><br></div><div>1. Renaming the directory to lib/clang/Tooling/Refactor. Requires updating all #include lines referring to it, and updating a handful of CMake files.</div><div><br></div><div>2. Renaming the library to clangToolingRefactoring. Requires updating all cmake files adding a dependency to use the new library name.</div></div></div></blockquote><div>Renaming the library is a less invasive change, less likely to screw with out-of-tree modifications, pending patches, other build systems.</div><div>So unless anyone has a strong opinion on what the better name is (I don't), I'd prefer #2.</div></div></div></blockquote><div><br></div><div>+1 to fixing the build system to give the library a consistent name. </div></div></div></blockquote><div><br></div><div>Cool, <a href="https://reviews.llvm.org/D62420">https://reviews.llvm.org/D62420</a> . Turns out the patch for 2 is tiny. </div></div></div>