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

[Nico Weber via cfe-dev]

On Fri, May 24, 2019 at 2:31 PM Richard Smith <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> 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.
>

Cool, https://reviews.llvm.org/D62420 . Turns out the patch for 2 is tiny.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190524/a5a5d7d5/attachment.html>