[LLVMdev] To APR Or Not To APR. That is the question.

[Reid Spencer]

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>