llvm dev - Aug 2015 - [LLVMdev] [RFC] Developer Policy for LLVM C API

On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Chiming in with http://reviews.llvm.org/D10725
>
> Being able to read and generate IR is at least some very basic thing we
> can agree on is needed. Can we get some testing for it ? Personally I
don't
> really mind if this is going to be stable or not, but at least, having some
> test coverage would allow to take whatever path that is going to be taken
> willingly.
>
>
Right, and that's the problem. Expanding the C API to cover reading and
generating IR in a stable way will lock the C++ API down in a way that I'm
not comfortable with - I think it has already gone too far.

-eric

> I'd like also to remind all to not fall into the hypothetical nirvana
> fallacy, ie comparing proposed solution with an idealized and unrealized
> one. That's a good recipe for endless bikescheding when pretty much
> anythign would be better than the status quo.
>
> 2015-07-17 12:36 GMT-07:00 Juergen Ributzka <juergen at apple.com>:
>
>> Hi @ll,
>>
>> a few of us had recently a discussion about how to manage the C API and
>> possible policies regarding addition, maintenance, deprecation, and
removal
>> of API.
>>
>> Even thought there is a strong agreement in the community that we
>> shouldn't break released C API and should be backwards compatible,
there
>> doesn’t seem to be a developer policy that backs that up. This is
something
>> we should fix.
>>
>> I was wondering what the interested parties think of the current
approach
>> and what could/should we improve to make the use and maintenance of the
C
>> API easier for users and the developers alike.
>>
>> I was hoping we could also introduce a process that allows the removal
of
>> an API after it has been deprecated for a whole release and the release
>> notes stated that it will be removed.
>>
>> Thoughts? Comments?
>>
>> Cheers,
>> Juergen
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150817/5cbdf3c4/attachment-0001.html>

2015-08-16 21:47 GMT-07:00 Eric Christopher <echristo at gmail.com>:
>
>
> On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Chiming in with http://reviews.llvm.org/D10725
>>
>> Being able to read and generate IR is at least some very basic thing we
>> can agree on is needed. Can we get some testing for it ? Personally I
don't
>> really mind if this is going to be stable or not, but at least, having
some
>> test coverage would allow to take whatever path that is going to be
taken
>> willingly.
>>
>>
> Right, and that's the problem. Expanding the C API to cover reading and
> generating IR in a stable way will lock the C++ API down in a way that
I'm
> not comfortable with - I think it has already gone too far.
>
> -eric
>
That seems like a bare minimum.

The C++ evolve from one version to another, what is preventing the C API to
do the same ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150816/892f3449/attachment.html>

On Sun, Aug 16, 2015 at 9:49 PM deadal nix <deadalnix at gmail.com> wrote:
> 2015-08-16 21:47 GMT-07:00 Eric Christopher <echristo at gmail.com>:
>
>>
>>
>> On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Chiming in with http://reviews.llvm.org/D10725
>>>
>>> Being able to read and generate IR is at least some very basic
thing we
>>> can agree on is needed. Can we get some testing for it ? Personally
I don't
>>> really mind if this is going to be stable or not, but at least,
having some
>>> test coverage would allow to take whatever path that is going to be
taken
>>> willingly.
>>>
>>>
>> Right, and that's the problem. Expanding the C API to cover reading
and
>> generating IR in a stable way will lock the C++ API down in a way that
I'm
>> not comfortable with - I think it has already gone too far.
>>
>> -eric
>>
>
> That seems like a bare minimum.
>
> The C++ evolve from one version to another, what is preventing the C API
> to do the same ?
>
>
The promise of stability. We don't promise that the C++ API will stay
stable.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150817/03b052d0/attachment.html>