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: <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 llvm.cs.uiuc.edu > 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 -- llvm.org 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 (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 cs.uiuc.edu/~vadve 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 llvm.cs.uiuc.edu > 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: <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 > cs.uiuc.edu/~vadve > 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 llvm.cs.uiuc.edu > mail.cs.uiuc.edu/mailman/listinfo/llvmdev > > > ______________________________________________________________________ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu llvm.cs.uiuc.edu > 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: <lists.llvm.org/pipermail/llvm-dev/attachments/20040916/6cf8808b/attachment.sig>
Andrew Lenharth
2004-Sep-17 04:08 UTC
[LLVMdev] To APR Or Not To APR. That is the question.
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: <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 llvm.cs.uiuc.edu > mail.cs.uiuc.edu/mailman/listinfo/llvmdev