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

[Mehdi AMINI via llvm-dev]

2017-05-31 22:03 GMT-07:00 Zachary Turner <zturner at google.com>:

> 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.
>

Right, to clarify: that is exactly my view as well at this point :)

-- 
Mehdi


>
> 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/20170531/489f3f93/attachment.html>