[cfe-dev] The name of clang/lib/Tooling/Refactoring

[Alex Lorenz via cfe-dev]

I’m fine with renaming the directory lib/Tooling/Refactoring to lib/Tooling/Refactor. Renaming the library to be consistent is a good step forward as well, so thumbs up from me. If there’s still interest after renaming the library, I can make a patch that renames the directory as well. We have some not-yet-upstreamed code in apple/swift-clang on Github that will be affected, but I will take care of it.

Thanks,
Alex

> On May 24, 2019, at 12:40 PM, Nico Weber via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> On Fri, May 24, 2019 at 2:31 PM Richard Smith <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
> On Fri, 24 May 2019 at 09:57, Sam McCall via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> On Fri, May 24, 2019 at 6:28 PM Nico Weber <thakis at chromium.org <mailto:thakis at chromium.org>> wrote:
> On Fri, May 24, 2019 at 4:34 AM Ilya Biryukov <ibiryukov at google.com <mailto:ibiryukov at google.com>> wrote:
> 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.
> 
> I find this kind of argument not very convincing. See e.g. the first 7 slides of https://www.usenix.org/sites/default/files/conference/protected-files/srecon17americas_slides_reese.pdf <https://www.usenix.org/sites/default/files/conference/protected-files/srecon17americas_slides_reese.pdf>
> 
> We've renamed many libraries to increase consistency, and we know from experience it's a pretty safe thing to do.
> I've dealt with the fallout from one of these renames recently - we silently lost some changes during a (non-git, non-svn) merge.
> The unsafeness of it may not be visible from upstream LLVM :-)
> 
> 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.
> 
> If we do rename, do folks prefer:
> 
> 1. Renaming the directory to lib/clang/Tooling/Refactor. Requires updating all #include lines referring to it, and updating a handful of CMake files.
> 
> 2. Renaming the library to clangToolingRefactoring. Requires updating all cmake files adding a dependency to use the new library name.
> Renaming the library is a less invasive change, less likely to screw with out-of-tree modifications, pending patches, other build systems.
> So unless anyone has a strong opinion on what the better name is (I don't), I'd prefer #2.
> 
> +1 to fixing the build system to give the library a consistent name. 
> 
> Cool, https://reviews.llvm.org/D62420 <https://reviews.llvm.org/D62420> . Turns out the patch for 2 is tiny. 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190524/072c95df/attachment.html>