<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Oct 12, 2016 at 1:23 AM David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12 Oct 2016, at 07:29, Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg"><br>><br class="gmail_msg"><br>> I'm generally favorable on the core idea of having a type-safe and friendly format-string-like formatting utility<br class="gmail_msg"><br><br class="gmail_msg"><br>I’m also generally in favour, but I wonder what the key motivations for designing our own, rather than importing something like FastFormat, fmtlib, or one of the other tried-and-tested C++ typesafe I/O libraries is.  Has someone done an analysis of why these designs are a bad fit for LLVM, or are we just reinventing the wheel because we feel like it?<br class="gmail_msg"></blockquote><div><br></div><div>(this keeps coming up in various contexts, so a somewhat longer/in-depth post than I originally intended. If folks want to discuss this further should probably fork a new thread)</div><div><br></div><div>Given the tendency of utilities like this to become used pervasively in the project, it would seem a fairly heavy weight dependency to grow.</div><div><br></div><div>I understand that LLVM's refusal to depend on and re-use existing open source code is frustrating, I'm actually rather frustrated as well at times by the NIH-like pattern. But I think there are good reasons for LLVM to eschew third party libraries in its core utilities, not the least of which are the inherent licensing complications.</div><div><br></div><div>LLVM faces a somewhat unique challenge when it comes to licensing compared to most other open source software: parts of LLVM are embedded into the binaries we build. This makes finding a "compatibly licensed" existing project .... unlikely. ;]</div><div><br></div><div>I don't want to spin off on a debate here about which license LLVM should use or not use or what all it needs to say. We have a separate thread about that. But one hope I have of *any* resolution ta that thread is that perhaps more open source projects will use exactly the same license. If they do, we might finally be able to have more reuse of existing open source code.</div><div><br></div><div><br></div><div>Either way, rolling our own has some advantages: LLVM may be able to make simplifying tradeoffs other libraries cannot realistically make due to narrower use cases and needs.</div><div><br></div><div>Provided we're only talking about very low level utilities like this, the cost doesn't seem terribly high to rolling our own, so I'm generally comfortable doing it.</div><div><br></div><div>Doesn't mean we shouldn't look at all the existing ones and learn everything we can from them.</div><div><br></div><div>-Chandler</div><div><br></div></div></div>