<div dir="ltr">On Fri, Feb 8, 2013 at 3:05 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank" class="cremed">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 8 Feb 2013, at 09:53, Chandler Carruth wrote:<br>
<br>
> I also think you should remember that it is explicitly *not* a goal of the LLVM project to optimize its development process for out-of-tree projects, and instead it *is* a goal to optimize the development process for in-tree efforts.<br>

<br>
</div>From the front page of the LLVM web site, point number 1:<br>
<br>
> • The LLVM Core libraries provide a modern source- and target-independent optimizer, along with code generation support for many popular CPUs (as well as some less common ones!) These libraries are built around a well specified code representation known as the LLVM intermediate representation ("LLVM IR"). The LLVM Core libraries are well documented, and it is particularly easy to invent your own language (or port an existing compiler) to use LLVM as an optimizer and code generator.<br>

<br>
It explicitly IS a goal (and, indeed, a very important goal as it is one of our key differentiators from other compiler projects) for the LLVM project to provide reusable, well-documented, libraries.<br>
<br>
There is no mention of a distinction between in and out of tree users, and the implication here is strongly that out of tree users are encouraged (we don't typically accept invented languages or ports of existing compilers to use LLVM in the tree).<br>
</blockquote><div><br></div><div style>I never said we don't provide re-usable libraries, or that we don't encourage out-of-tree users. I was talking specifically (and exclusively) about the development process.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am concerned that you believe that out-of-tree consumers are unimportant.</blockquote><div><br></div><div style>
I don't believe that, nor did I say anything of the sort. This is shifting the entire discussion to something else entirely. Let's focus on the real issue.</div><div><br></div><div style><br></div><div style>The only thing I am talking about here is the C++ APIs. LLVM has had essentially zero API stability guarantees for its C++ interfaces for at least the last 6 years I have been following the project. That is nothing new. We do support users of LLVM who have a need for API stability with a stable C interface. That interface even tries to provide (although we're not perfect here by any means) ABI stability.</div>
<div style><br></div><div style>When building an external project that uses the LLVM libraries, there are two interfaces to choose from: the C++ one which provides a rich and deep interface, but which changes rapidly on trunk, or the C interface which provides a narrow and high-level interface that is stable from release to release. It's a tradeoff. Many people don't use the C interface because it is incomplete or doesn't support their use case. However, if you need API stability, I think the correct approach is to contribute patches enhancing the C interface until it is sufficient for the particular use cases you have.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> I think this is a good thing, and unlikely to change. As such, I think staging documentation updates to follow after the APIs stabilize is not a completely unreasonable or unacceptable approach.<br>

<br>
</div>I am concerned by the idea that documentation should come after development.  This is a very strange workflow as it indicates that design happens after coding.  While this is common in some projects, I would hope that LLVM would hold itself to a higher standard.  The mindset of code-first, think-second (document third, if at all) can be incredibly destructive to even an established project, as we have seen in a large number of open source and proprietary software systems.<br>
</blockquote><div><br></div><div style>While I don't entirely agree that it is as black-and-white as you make it out (specifically, I'm confident that Bill thought before coding, as we had several design discussions), I also don't really disagree with the underlying point. But if you believe strongly that there is a better way to develop LLVM, the best way to shift the practices of LLVM developers is to lead by example. Contribute patches that clearly show how you would refactor APIs and improve the core of LLVM, with documentation early on. That will be a much more productive way to convince people than debating it on a mailing list.</div>
</div></div></div>