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

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Wed May 31 21:36:48 PDT 2017


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/44f9123d/attachment.html>


More information about the llvm-dev mailing list