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

[Vikram Adve]

Reid,

Adding APR as one possible implementation of lib/System makes sense, 
and is what I originally suggested when I brought up the question of 
using APR.  In particular, I agree that we want to keep APR or any 
other similar layer encapsulated behind lib/System.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/


On Sep 13, 2004, at 10:34 AM, Reid Spencer wrote:

> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3292 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040916/a45ace02/attachment.bin>