search for: disincentivizing

...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? --Owen -...

...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) be *t...

...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?...

I had considered a libraries/Backends:Other as well that would be separate from libraries/Other On Fri, Nov 9, 2018 at 11:20 AM Derek Schuff <dschuff at google.com> wrote: > 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

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