[LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API

[Chandler Carruth]

On Fri, Feb 8, 2013 at 3:05 AM, David Chisnall
<David.Chisnall at cl.cam.ac.uk>wrote:

> On 8 Feb 2013, at 09:53, Chandler Carruth wrote:
>
> > 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.
>
> From the front page of the LLVM web site, point number 1:
>
> > • 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.
>
> 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.
>
> 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).
>

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.

I am concerned that you believe that out-of-tree consumers are unimportant.


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.


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.

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.


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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/6b20323d/attachment.html>