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

[Richard Smith via cfe-dev]

On Fri, 24 May 2019 at 09:57, Sam McCall via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> On Fri, May 24, 2019 at 6:28 PM Nico Weber <thakis at chromium.org> wrote:
>
>> On Fri, May 24, 2019 at 4:34 AM Ilya Biryukov <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
>>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190524/925c7513/attachment.html>