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

[Michael Spencer via llvm-dev]

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. Given that I don't think use
outside of llvm is a great line to split on.

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170531/dde81afe/attachment.html>