similar to: [LLVMdev] clarification to copyright section of developer policy

Am 23.09.2010 19:44, schrieb Chris Lattner: > In practice, copyright assignment is > really only useful (afaik) for two things: > > 1) being able to change the copyright in the future. 2) having a > single entity to down violators of the license. > > Since neither of these are really interesting goals for the project, > having distributed copyright is not a problem. Not

All, A draft of the LLVM Developer Policy document has been committed. This is something the Oversight Group has been working on for quite a while now. It defines policies regarding copyright, licensing, communication, quality, testing, patches, commit access, etc. We developed this so that everyone can be on the same page with respect to these policies. You can read it on-line here:

Hi, I’ve noted some change in wording on the current (4.0) developer policy[1], compared to the 3.9 developer policy[2]. Specifically the part about IR Backwards Compatibility. The change from 3.9 to 4.0 is the following: - The textual format is not backwards compatible. We don’t change it too often, but there are no specific promises. - Additions and changes to the IR should be reflected

On Aug 18, 2015, at 10:41 PM, deadal nix <deadalnix at gmail.com> wrote: > Let's not get this die. The C API is too valuable to let this die. > > I propose the following plan: > - Add tests for the current API. This will allow to make sure that everything works and would ensure that changes are made intentionally, nto accidentally. > - For area that do not exist in the

Something that would be good to get clarity on: The RISC-V backend recently had a bugfix patch that got backported to the 10.0.1 branch. The original patch introduced a new virtual method in TargetLowering.h, and the backported patch [1] was rewritten to avoid changing the ABI of libLLVM.so. This feels like some kind of policy decision about the C++ ABI beyond "it's entirely

> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > I can find old threads about it, but nothing saying why it was decided > that contributor agreement wouldn't work. Care to send the URL? Here are some quick points that come to mind: 1. It raises the bar to contribution, because something must be “signed” before a

On Mar 13, 2013, at 6:40 AM, Moritz Maxeiner <moritzmaxeiner at googlemail.com> wrote: > Hi, > > If I write LLVM bindings for a language X, in which I obviously > need to at least use parts of the llvm-c headers (constants, enums, typedefs, function names and > signatures) do I need to include the LLVM copyright notice? > > Whereas llvm-c has multiple headers (e.g.

On 03/13/2013 07:26 PM, Chris Lattner wrote: > LLVM's license includes a binary redistribution clause: > http://llvm.org/docs/DeveloperPolicy.html#license Hi Chris, the problem with the binary redistribution clause is that the bindings will not be linked with any part of LLVM. The bindings will load an LLVM shared library (dll/so/dylib) at runtime and thus an application compiled

> On Jul 26, 2016, at 12:16 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov> wrote: >> I think there are different kinds of inflexibility. We will use our collective professional judgment. There are some large-scale design changes that we might decide can happen over time. Whatever we decide to accept,

On Mar 13, 2013, at 12:17 PM, Moritz Maxeiner <moritzmaxeiner at googlemail.com> wrote: > On 03/13/2013 07:26 PM, Chris Lattner wrote: >> LLVM's license includes a binary redistribution clause: >> http://llvm.org/docs/DeveloperPolicy.html#license > > Hi Chris, > > the problem with the binary redistribution clause is that the bindings will not be linked with

This has already been discussed extensively in the public. The threads are available in the archives. -Chris > On Aug 10, 2017, at 1:05 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Sorry, but I really don't think a private conversation is appropriate > for such discussions. > > If the motive cannot be explained in public I have no choice

Dear R'sians.. I apologize if this topic has been beaten to death and hope that hawks don't pounce on me! Could you please suggest an efficient way to filter rows from 500+ text files (some with 30000+ rows with multiple section table headers) residing in several folders? I guess probably "scan" is the fastest way to scan a file, but, I noticed it sometimes takes a long time

Am 01.11.2011 05:59, schrieb Marc J. Driftmeyer: > Then this complaint about build times and extra CPU cycles when you're > living in a world of systems soon to average 16GB of RAM, 4-12 cores and > GPUs that would make any old Animator dream back in the '90s really > makes me laugh. Not disagreeing about the rest, but here I have to. In today's projects, full rebuilds

On 13 October 2015 at 09:19, Joachim Durchholz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Oh... why do I need to rebase? If your project is a product that wants to benefit from the advances of LLVM over the years, you'll have to update the code to the newer versions some time. Moreover, if you do find a bug, and it's in an old version, you won't have the same response

On 1 October 2013 15:40, Nicholas White <n.j.white at gmail.com> wrote: > Thanks - how would I go about getting this committed? I can commit it for you or you can apply for commit access. http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access Cheers, Rafael

The Developer Policy document (https://llvm.org/docs/DeveloperPolicy.html) contains a Section "C API Changes". There is no corresponding section for C++ API Changes. LLVM is somewhat different from most libraries in that the main language is C++ but the C++ API is not guaranteed to be stable in any shape or form from what I understand. I think it would be useful to have a "C++ API

A bit of history first: Back when we transitioned from bytecode to bitcode (2.0) we had a tool called llvm-upgrade which would read .ll files from 1.9 and output 2.0 format which could then be passed to llvm-as to produce bitcode. The release notes for 2.3 note that llvm-upgrade was not supported any more. During the 2.X development we tried to keep reading older bitcodes. Once we got to 3.1,

Hi Rafael, We’ve discussed why a license change is preferable over the span of several years now. I’m happy to explain over the phone, contact me off list and we can talk. -Chris > On Aug 10, 2017, at 8:33 AM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Hi, > > I still don't see any justification in the text why a license change is >

Hi all, Now that we’ve settled on the license legalese to get to, we need to start the process of relicensing. We’re still sorting through all of the details of what this will take, but the first step is clear: new contributions to LLVM will need to be under both the old license structure and the new one (until the old structure is completely phased out). From a mechanical perspective, this is

> On Jul 26, 2016, at 4:36 PM, Renato Golin <renato.golin at linaro.org> wrote: > > I'm most certainly not. Just because I didn't write something, that I means I have written the opposite.= > I’m failing to reconcile what you’re claiming above with the following that is in your proposal: "The target's code must have been adapted to the developers policy as