llvm dev - Sep 2004 - [LLVMdev] To APR Or Not To APR. That is the question.

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>

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