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

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>

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.
Okay.

We excised boost because we were only using a small subset of it that we 
could have written ourselves.  If boost as a whole does what we need, I 
think it could become an option again (although, IIRC, boost does not 
have uniform copyrights like Apache does, we was giving me a headache, 
so that might be an issue).

Were there any other reasons to not consider boost?  I'm not suggesting 
we use it; I'm just curious.
> 
> 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.
I think this approach would be good for transitioning over to APR.

However, I don't really like the idea of having two facilities in LLVM 
to do the same thing (namely, platform abstraction).  If APR lives up to 
its goal, then we should eventually be able to use it as *the* platform 
abstraction library, in which case, I think it should go into the source 
tree so that people don't have to install it in order to install LLVM.

I think trying out APR as you and Chris have suggested above would be a 
good way to see whether or not it will really work without committing 
completely to it.  When we know it will work, we can discuss whether it 
should go into the source tree or not.  Cross that bridge when we get to 
it sort of a thing.

-- John T.
> 
> 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

-- 
*********************************************************************
* 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.          *
*********************************************************************

On Mon, 13 Sep 2004, John Criswell wrote:
> Were there any other reasons to not consider boost?  I'm not suggesting
> we use it; I'm just curious.
The main reason we got rid of boost is it's configuration system which
looks at particular compilers and versions.  This was a pain to maintain
(it needed to be hacked every time a new gcc came out).  Also, boost
provides a ton of stuff we don't need, and does not provide a ton of stuff
we do need.  *shrug*
> However, I don't really like the idea of having two facilities in LLVM
> to do the same thing (namely, platform abstraction).  If APR lives up to
> its goal, then we should eventually be able to use it as *the* platform
> abstraction library, in which case, I think it should go into the source
> tree so that people don't have to install it in order to install LLVM.
Again, as mentioned, APR does not provide everything we need, so I don't
know if there is a way around this.

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/

John Criswell wrote:
> Okay.
>
> We excised boost because we were only using a small subset of it that we
> could have written ourselves.  If boost as a whole does what we need, I
> think it could become an option again (although, IIRC, boost does not
> have uniform copyrights like Apache does, we was giving me a headache,
> so that might be an issue).
Regarding copyrights:
1. All of them fulfill Boost copyright requirements, which means they all as 
as free as possible.
2. An effort is going on to move all Boost to a unified license 
(http://boost.org/LICENSE_1_0.txt) and a lot of process is made already.


Just  FYI.

- Volodya

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>

On Thu, 2004-09-16 at 07:36, Vikram Adve wrote:
> Reid,
> 
> Adding APR as one possible implementation of lib/System makes
> sense,and is what I originally suggested when I brought up the
> question ofusing APR.  In particular, I agree that we want to keep APR
> or anyother similar layer encapsulated behind lib/System.
Yes.

What I might do is send the APR email list a "wish list" of things
we'd
like to see. If/when they get implemented on enough platforms, I could
do the port. Doing it now is just silly because there's such little
support for things we need.

Reid.
> 
> --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 findthe
>         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 inthis
>         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 ourlicensing 
>                 (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 timesink, 
>                 especially with our limited access to other
>                 platforms.  And addingthird 
>                 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 problemlies 
>                 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 ifit 
>                 works.
>                 
>                 Are there any other libraries available that will do
>                 the things weneed 
>                 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
> 
> 
> ______________________________________________________________________
> _______________________________________________
> 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: 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/20040916/6cf8808b/attachment.sig>

I reallize I am responding to this thread a bit late, but here goes.

On Mon, 2004-09-13 at 10:34, Reid Spencer wrote:
> Snip snip snip, cut cut cut
> 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.
As someone who has had to work on and with software written against ACE
(the TAO codebase in fact) may I strongly suggest that you give no
further time to this idea.  Really, if for no other reason than the time
it takes gdb to load the debug synbols for ACE can be on the order of a
couple minutes.  To say it is heavy weight is an understatement.  It
insists on working on very non-standards compliant C++ compiles (i.e.
ones with little support for templates or stl), thus reimplements many
things in the standard library in a really C-type-unsafe way.

Just my 1/2 cent on ACE.

As for APR, when I had glanced at it briefly, it (of course) seemed
rather more focused on providing the things you need for sane cross
platform networking code.  It wasn't clear to me that this really
translated into providing everything we need nor provided useful
abstractions for what we did.  And do we really want to write a wrapper
to wrap another wrapper?

Andrew
-------------- 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/20040916/fc9c00aa/attachment.sig>

Agreed on all points. I've used ACE on a commercial product and its a
behemoth.
Debugging as you suggested is a nightmare.

APR is focused on networking support (and it does a pretty good job there) but 
that's to be expected since its principal use is in Apache HTTPD. For lots
of
things that we need, APR just has no support which is why it won't get 
implemented in lib/System for a while (until it can do things that we need it 
to do).

And that's a "wrap".

Reid.

Andrew Lenharth wrote:
> I reallize I am responding to this thread a bit late, but here goes.
> 
> On Mon, 2004-09-13 at 10:34, Reid Spencer wrote:
> 
>>Snip snip snip, cut cut cut
>>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.
> 
> 
> As someone who has had to work on and with software written against ACE
> (the TAO codebase in fact) may I strongly suggest that you give no
> further time to this idea.  Really, if for no other reason than the time
> it takes gdb to load the debug synbols for ACE can be on the order of a
> couple minutes.  To say it is heavy weight is an understatement.  It
> insists on working on very non-standards compliant C++ compiles (i.e.
> ones with little support for templates or stl), thus reimplements many
> things in the standard library in a really C-type-unsafe way.
> 
> Just my 1/2 cent on ACE.
> 
> As for APR, when I had glanced at it briefly, it (of course) seemed
> rather more focused on providing the things you need for sane cross
> platform networking code.  It wasn't clear to me that this really
> translated into providing everything we need nor provided useful
> abstractions for what we did.  And do we really want to write a wrapper
> to wrap another wrapper?
> 
> Andrew
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev