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

On Fri, Jul 17, 2015 at 3:41 PM, Eric Christopher <echristo at gmail.com>
wrote:
> Hi Juergen,
>
> I've actually got another, perhaps more radical, plan. Let's just
get rid
> of the C API or move it to another project. This simplifies a lot of the
> plans here where people have too many different ideas of how the C API
> should work.
>
> At this point the people who want a stable C API per incremental version
> can do that and handle the overhead of porting themselves and the people
> that want a C API that just happens to be a C interface can have a wrapper
> (or SWIG or whatever they want).
>
> I realize it's radical, but it seems that there are so many different
> wants for C API here that solving everyone's problems or wants is going
to
> be impossible.
>
I am strongly in favor of moving the bindings, C or otherwise, to another
project.

>
> -eric
>
> On Fri, Jul 17, 2015 at 12:39 PM Juergen Ributzka <juergen at
apple.com>
> wrote:
>
>> 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
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/7acc46a1/attachment.html>

----- Original Message -----
> From: "David Majnemer" <david.majnemer at gmail.com>
> To: "Eric Christopher" <echristo at gmail.com>
> Cc: "Lang Hames" <lhames at apple.com>, "LLVM
Dev" <llvmdev at cs.uiuc.edu>
> Sent: Friday, July 17, 2015 7:11:57 PM
> Subject: Re: [LLVMdev] [RFC] Developer Policy for LLVM C API
> 
> On Fri, Jul 17, 2015 at 3:41 PM, Eric Christopher <
> echristo at gmail.com > wrote:
> 
> 
> 
> Hi Juergen,
> 
> 
> I've actually got another, perhaps more radical, plan. Let's just
get
> rid of the C API or move it to another project. This simplifies a
> lot of the plans here where people have too many different ideas of
> how the C API should work.
> 
> 
> At this point the people who want a stable C API per incremental
> version can do that and handle the overhead of porting themselves
> and the people that want a C API that just happens to be a C
> interface can have a wrapper (or SWIG or whatever they want).
> 
> 
> I realize it's radical, but it seems that there are so many different
> wants for C API here that solving everyone's problems or wants is
> going to be impossible.
> 
> 
> I am strongly in favor of moving the bindings, C or otherwise, to
> another project.
I agree. From my viewpoint we have two primary problems with the C API:

 1. Many of the LLVM contributors don't use it, and thus, don't have a
great understanding of how it can be most-usefully updated/improved, and what
functionality needs to be exposed. We have most, but not all, transformations;
many, but not all, IR features, etc.

 2. We don't have a good set of tests for it, nor do we have a good set of
tutorials/documentation for it. Our tutorials, specifically, are in C++, not in
C. We could break the C API and we'd likely remain unaware for quite awhile.

Putting it in a separate project will force those who have a stake in its
existence to take the responsibility of moving it forward. Separate project, or
not, however, we should have a better developer policy regarding the C API (and
the other bindings) that fall under the LLVM umbrella. Specifically, we should
outline what features need to be exposed, and we should actively maintain (and
test for) full coverage of those features.

 -Hal
> 
> -eric
> 
> 
> 
> On Fri, Jul 17, 2015 at 12:39 PM Juergen Ributzka < juergen at apple.com
> > wrote:
> 
> 
> 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
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
>> I am strongly in favor of moving the bindings, C or otherwise, to
>> another project.
> 
> I agree. From my viewpoint we have two primary problems with the C API:
> 
> 1. Many of the LLVM contributors don't use it, and thus, don't have
a great understanding of how it can be most-usefully updated/improved, and what
functionality needs to be exposed. We have most, but not all, transformations;
many, but not all, IR features, etc.
> 
> 2. We don't have a good set of tests for it, nor do we have a good set
of tutorials/documentation for it. Our tutorials, specifically, are in C++, not
in C. We could break the C API and we'd likely remain unaware for quite
awhile.
> 
> Putting it in a separate project will force those who have a stake in its
existence to take the responsibility of moving it forward. Separate project, or
not, however, we should have a better developer policy regarding the C API (and
the other bindings) that fall under the LLVM umbrella. Specifically, we should
outline what features need to be exposed, and we should actively maintain (and
test for) full coverage of those features.
I don’t understand the motivation for this.  Is there tension between clients of
the C API that would warrant having different approaches/implementations? 
Moving it out to a subproject to get better testing seems a bit silly.

Personally, unless there is a strong and compelling reason to do so, I’d prefer
to keep a single set of C bindings to encourage standardization and avoid
fragmenting the community.

-Chris

> On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> 2. We don't have a good set of tests for it, nor do we have a good set
of tutorials/documentation for it. Our tutorials, specifically, are in C++, not
in C. We could break the C API and we'd likely remain unaware for quite
awhile.
I think this is the most important point, that we lack testing for it.

IMO, the language doesn’t matter too much.  I’m happy with C or C++, but
whichever (or both) or those are exposed in a stable way, we need the *users* of
those APIs to help test it.

How about we add a StableAPI directory in unittests?  Then have a test written
in C/C++ for each of the users of it.  So a WebKit.c test, Go.c,
SomeProject.cpp, etc.

Then adding anything to the stable API must have a corresponding test, and
changing the API shows us exactly which test broke, who cares about that test,
and who to talk to about updating that API if we need to.  If the only test
which breaks is WebKit then talk to WebKit, if its Go too then add them in, and
so on.

Sure the tests will get large, but thats the point.  It would show us exactly
what API users care about.  And the tests don’t need to actually run anything,
just ensure that methods signatures are compatible with what they are using.

Cheers,
Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150720/4dd40480/attachment.html>