On Sep 12, 2004, at 9:52 PM, Vikram Adve wrote:> I think we should be careful to isolate APR behind a "complete" > lib/System interface, i.e., not use it directly anywhere. If we do > that, it becomes strictly an implementation convenience and the > dependence is limited to that one part of the system. > > One concern I have with APR is their use of pool allocation for memory > management. It seems to pervade many of their APIs. Does anyone know > (a) whether their pool allocators are optional or required, and (b) if > it has be used for the library side, does it also have to be used on > the client side? I think we should stay away from any pool allocation > within LLVM. We're about to have a whole Ph.D. thesis showing why > it's a bad idea :-) > > Aside from this issue, I'm in favor of using it directly and not > wasting effort maintaining partial, and quite likely imperfect, > lib/System implementations of our own on multiple platforms. I > believe exploiting reasonable, mature, and long-lived external > technology is the right thing to do any time it saves us significant > development effort.I should also add that (I think) we should only use software that can be redistributed freely by us in any form (so that LLVM continues to work "out-of-the-box"), and which has a license roughly as liberal as LLVM does. In particular, we can't include any GPL software directly within the LLVM distribution. I looked through the Apache license and I think it's ok on these two issues: http://www.apache.org/licenses/LICENSE-2.0.html --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/
Dear All, Time to add my two cents: I think incorporating something like APR into the LLVM tree is fine, given that it works, its licensing doesn't interefere with our licensing (and doesn't give me a headache), and we can merge it into the LLVM source base relatively seamlessly (i.e. users don't need to install it before building LLVM and APR plays nice with our build system). I think building our own lib/System is going to be a bit of a time sink, especially with our limited access to other platforms. And adding third party libraries is okay as long as the user doesn't have to install extra stuff to use LLVM. The licensing, I think, will be okay. The remainder of the problem lies with how well APR works and how well it will integrate with our build system. For that, I think we'll simply have to try it out and see if it works. Are there any other libraries available that will do the things we need to do? It strikes me that we haven't enumerated what we need and what our options are. If we go ahead and do incorporate APR, I would recommend the following: a) Keep APR as a separate library and write lib/System as a wrapper around it. b) Maintain a vendor branch for APR so that changes from the Apache Foundation are more easily merged into the tree (the CVS docs describe how to do this in the "Tracking Third Party Sources" section). -- John T. -- ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu * * Research Programmer * * University of Illinois at Urbana-Champaign * * * * "It's today!" said Piglet. "My favorite day," said Pooh. * *********************************************************************
John, If we were to do this, I don't think that adding it to the LLVM source base is the right way to go. We would simply use "configure" to find the library and header files. The moment we put APR into our source base, it would be out of date. Keeping it up to date would not be fun for anyone and there's no reason for us to do that. Furthermore, this approach completely avoids any licensing issues. We wouldn't distribute APR, just use it (even though Apache's license is relatively tame). As for other libraries, there is boost (which we've already excised), and ACE (which is huge and heavy weight). APR is the rising star in this area. I think Chris had the right idea: make APR "one" of the possible implementations. That is, make it possible for the user to configure LLVM so that it thinks the operating system its building for is "APR". All we have to do is create an APR directory in lib/System and the necessary functions in configure.ac to allow it to be specified as the host operating system. I think I might do this regardless of what the decision on this issue is because it would at least give new platforms a shot at having LLVM work. Reid. On Mon, 2004-09-13 at 08:18, John Criswell wrote:> Dear All, > > Time to add my two cents: > > I think incorporating something like APR into the LLVM tree is fine, > given that it works, its licensing doesn't interefere with our licensing > (and doesn't give me a headache), and we can merge it into the LLVM > source base relatively seamlessly (i.e. users don't need to install it > before building LLVM and APR plays nice with our build system). > > I think building our own lib/System is going to be a bit of a time sink, > especially with our limited access to other platforms. And adding third > party libraries is okay as long as the user doesn't have to install > extra stuff to use LLVM. > > The licensing, I think, will be okay. The remainder of the problem lies > with how well APR works and how well it will integrate with our build > system. For that, I think we'll simply have to try it out and see if it > works. > > Are there any other libraries available that will do the things we need > to do? It strikes me that we haven't enumerated what we need and what > our options are. > > If we go ahead and do incorporate APR, I would recommend the following: > > a) Keep APR as a separate library and write lib/System as a wrapper > around it. > > b) Maintain a vendor branch for APR so that changes from the Apache > Foundation are more easily merged into the tree (the CVS docs describe > how to do this in the "Tracking Third Party Sources" section). > > -- John T.-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040913/b70716c0/attachment.sig>
Alexander Boström
2004-Oct-24 22:03 UTC
[LLVMdev] To APR Or Not To APR. That is the question.
mån 2004-09-13 klockan 06:45 +0000 skrev en okänd avsändare:> I should also add that (I think) we should only use software that can > be redistributed freely by us in any form (so that LLVM continues to > work "out-of-the-box"), and which has a license roughly as liberal as > LLVM does. In particular, we can't include any GPL software directly > within the LLVM distribution. I looked through the Apache license and > I think it's ok on these two issues: > http://www.apache.org/licenses/LICENSE-2.0.htmlAccording to http://www.gnu.org/philosophy/license-list.html the Apache Software License, version 2.0 is incompatible with the GPL. If LLVM would require the APR, then this could mean that GPL software would not be allowed to use LLVM, or perhaps only use it in certain ways (for example exec:ing binaries but not linking to libraries). /abo