[llvm-dev] A libc in LLVM

[Andrew Kelley via llvm-dev]

On 6/26/19 12:42 PM, Chris Lattner wrote:
> On Jun 26, 2019, at 9:02 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> On 6/24/19 6:23 PM, Siva Chandra via llvm-dev wrote:
>>> Within Google, we have a growing range of needs that existing libc
>>> implementations don't quite address.
>>> To be very clear: we don't expect our needs to exactly match everyone
>>> else's -- part of our impetus is to simplify things wherever we can, and
>>> that may not quite match what others want in a libc.
>>> There are also few areas which we do not intend to invest in at this point:
>>>    Implement dynamic loading and linking support.
>>>    Support for more architectures (we'll start with just x86-64 for
>>>    simplicity).
>>> So, what do you think about incorporating this new libc under the LLVM
>>> project?
>> The null hypothesis is to not add a project to LLVM. In order to add a
>> project, it should be justified. What are the justifications here? I've
>> quoted the snippets above where it is made clear that Google's needs do
>> *not* line up with the needs of the community. But the proposal failed
>> to mention what the actual needs of Google are.
>>
>> So what are they?
> 
> I really have nothing to do with this project, and no insight on the thoughts behind it, but I think you and several other people on this thread have missed a significant issue: the thread is conflating whether it is a good idea to "create yet another libc" with whether it is a good idea to "contribute that code to LLVM".  I don’t think arguing whether or not someone should build a project is on-topic for this list.  Given that they appear motivated to build it, the question is whether this fits into the LLVM umbrella.

I don't understand your reasoning here. If there's reason to believe it
should not be built at all, wouldn't that also imply that it shouldn't
be taken under LLVM's umbrella? The LLVM community (including myself)
will be responsible for maintaining this software and to do that we must
figure out the specifications, trade-offs, and use cases. How should we
determine the requirements of something that has no reason to exist?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/ee250ef4/attachment-0001.sig>