[llvm-dev] Should we split llvm Support and ADT?

[Zachary Turner via llvm-dev]

I'm somewhere in the middle.  I don't think we need to maintain build
files, documentation, upstream buildbots etc for using LLVMSupport out of
tree, but I do like the conceptual separation and I think "is this useful
outside of LLVM" is a good conceptual litmus test for what should go in
such a hypothetical library.

On Wed, May 31, 2017 at 9:36 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

> 2017-05-31 17:11 GMT-07:00 Michael Spencer <bigcheesegs at gmail.com>:
>
>> On Mon, May 29, 2017 at 10:22 AM, Mehdi AMINI via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> 2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>:
>>>
>>>> On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev <
>>>>> llvm-dev at lists.llvm.org>:
>>>>>
>>>>>> Changing a header file somewhere and having to spend 10 minutes
>>>>>> waiting for a build leads to a lot of wasted developer time.
>>>>>>
>>>>>> The real culprit here is tablegen.  Can we split support and ADT into
>>>>>> two - the parts that tablegen depends on and the parts that it doesn't?
>>>>>>
>>>>>
>>>>> Splitting ADT just based on tablegen usage seems dubious to me. If we
>>>>> need to go this route, I'd replace as many uses of ADT data structure with
>>>>> STL ones to begin with to reduce the surface.
>>>>>
>>>>
>>>> Tablegen would not need to determine WHERE to split, it would just
>>>> motivate the why.
>>>>
>>>
>>> Well even the why :)
>>> (note I was mentioning ADT and not Support above).
>>>
>>>
>>>
>>>>   It's obvious just from looking at Support's include directory though
>>>> that a lot of stuff in there doesn't belong together.  A quick look over
>>>> the include directory already suggests a split into "broadly useful stuff"
>>>> and "narrowly useful stuff"
>>>>
>>>
>>> I agree, Support is a mess IMO (we have target specific stuff here just
>>> for the sake of sharing code with clang AFAIK) and I'm not sure anyone
>>> would oppose to split it. Ideally the way I would split it would be such
>>> that it could (at some point) be useful outside of LLVM (just like ADT), so
>>> one main criteria could be "could this component of Support be useful
>>> outside of LLVM (and its subprojects)".
>>>
>>
>> While it would be nice to easily use parts of support outside of llvm (as
>> I've done on many occasions), I'm not sure the llvm project wants to
>> maintain and support a generic c++ library.
>>
>
> Sorry, I'm not sure to follow you, because my impression is that we're
> *already* maintaining a generic C++ library in-tree. The fact that the mess
> that is libSupport today does not allow to split ADT (or other generic
> utilities in libSupport) out-of-tree easily does not change that.
>
>
>> Given that I don't think use outside of llvm is a great line to split on.
>>
>
> I think on the opposite that it is a valuable line because it matches a
> conceptual layer.
>
> --
> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170601/eb773d01/attachment.html>