search for: disincentiv

...he topic. Maybe some of this is related to messaging - would the proposed project be *an* LLVM libc or *the* LLVM libc. There is already at least one instance within the LLVM umbrella where a subproject designed and built to a particular set of constraints became *the* LLVM solution, and ended up disincentivizing investment from contributors whose priorities didn't match those constraints. Staking the blessed-by-LLVM slot for a piece of the toolchain is not free. To turn the question around, why should *this* libc (assuming it will be built whether or not LLVM accepts it) be *the* LLVM libc? --O...

...e of this is related to > messaging - would the proposed project be *an* LLVM libc or *the* LLVM > libc. There is already at least one instance within the LLVM umbrella > where a subproject designed and built to a particular set of constraints > became *the* LLVM solution, and ended up disincentivizing investment from > contributors whose priorities didn't match those constraints. Staking the > blessed-by-LLVM slot for a piece of the toolchain is not free. > > To turn the question around, why should *this* libc (assuming it will be > built whether or not LLVM accepts it)...

...he topic. Maybe some of this is related to messaging - would the proposed project be *an* LLVM libc or *the* LLVM libc. There is already at least one instance within the LLVM umbrella where a subproject designed and built to a particular set of constraints became *the* LLVM solution, and ended up disincentivizing investment from contributors whose priorities didn't match those constraints. Staking the blessed-by-LLVM slot for a piece of the toolchain is not free. > > To turn the question around, why should *this* libc (assuming it will be built whether or not LLVM accepts it) be *the* LLVM l...

...I wonder if backends are a special case to the heuristic of "let's not > make a bug component for code components that are too small". LLVM is > factored to cleanly separate backend code, to the point where it's the one > thing you can leave out at compile time; this can disincentivize people to > care about bugs in backends that they don't use (and conversely backends > seem like the most common/best supported out-of-tree use case). There's > obviously a lot of variance in how actively-developed the backends are and > how many people care about them, but i...

Hi Zach, Thanks for elaborating. I like your proposal. I agree it still groups per area of expertise. And it makes the set of components we have easier to manage. Before making changes though I hope to hear opinions from others on this. What do others think? Thanks, Kristof On 9 Nov 2018, at 18:05, Zachary Turner <zturner at google.com<mailto:zturner at google.com>> wrote: To

Hello LLVM Developers, Within Google, we have a growing range of needs that existing libc implementations don't quite address. This is pushing us to start working on a new libc implementation. Informal conversations with others within the LLVM community has told us that a libc in LLVM is actually a broader need, and we are increasingly consolidating our toolchains around LLVM. Hence, we