[llvm-dev] A libc in LLVM

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 26 21:42:13 PDT 2019

On Jun 26, 2019, at 10:16 AM, Andrew Kelley <andrew at ziglang.org> wrote:
>> 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?

I don’t see the connection.  The LLVM project exists to foster compiler and toolchain related technologies that align with its developer policy (including license, library based design etc).  This proposal aligns directly with that mission.

I don’t see why something being part of LLVM means that you necessarily need to support it or “maintain" it.  Do you maintain vmkit, which is also part of LLVM?

OTOH, I agree with you that something becoming an LLVM subproject means that it is likely to gain traction over time and become a default answer with new targets that come up.  If there are other existing libc implementations that want to align with the mission (incl, design goals, coding standard, licensing, etc), then I encourage them to step up and provide other compelling alternatives to consider.

If no compelling alternative to consider steps forward, then the primary question (from the LLVM perspective) is whether a new project aligns with the mission or not.  We have no track record of rejecting a proposal based on the theory that some better alternative *could theoretically* exist.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/d53851c9/attachment.html>

More information about the llvm-dev mailing list