Folks,
I'm bringing the APR (Apache Portable Runtime) up for consideration as
the implementation of lib/System again. For those not familiar with it,
APR is the portability library used by the Apache Group and others in
open source projects such as HTTPD and Subversion. While its relatively
new, it is quickly gaining mind share and it provides lots of features
and supports numerous platforms today. For more details you can check
out: http://apr.apache.org/.
Our use of APR would be limited to the lib/System library. That is, we
would provide very thin C++ veneers on top of APR's C interface that
match the current lib/System and lib/Support APIs.
Since an APR implementation would get lib/System "done" on all our
platforms much faster than the current approach, I'd like to know if
anyone has any objections. Briefly, here's the upside/downside:
Upside:
* Get lib/System implemented on all platforms faster
* Avoid maintaining complicated platform independence code (the
gust of lib/System) so that our attention is not diverted from
compiler tool building.
* Faster bug fixing in this area because other developers are
working on it.
* Faster support for new platforms because other developers are
working on it.
Downside:
* Makes LLVM dependent on a third party library
* Makes LLVM platform support dependent on
* Error handling in APR is somewhat strange and it could be quite
difficult for us to continue to meet the "throw std::string"
approach we have today.
Silence on this issue will be taken as tacit approval. If you have any
objections/thoughts/questions, please post them so we can discuss.
Thanks,
Reid.
-------------- 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/20040912/383fad4d/attachment.sig>
On Sun, Sep 12, 2004 at 04:21:22PM -0700, Reid Spencer wrote:> Downside: > * Makes LLVM dependent on a third party library > * Makes LLVM platform support dependent on > * Error handling in APR is somewhat strange and it could be quite > difficult for us to continue to meet the "throw std::string" > approach we have today.I vote against making LLVM dependent on even MORE things that we do not control. At least with the current system, we get to define the interfaces, while putting in yet another tool, we are dependent on how it does things. I think the complexity of being dependent on large external libraries (APR, boost, et al) is enough of a downside to not incorporate them. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
On Sun, 2004-09-12 at 16:28, Misha Brukman wrote:> On Sun, Sep 12, 2004 at 04:21:22PM -0700, Reid Spencer wrote: > > Downside: > > * Makes LLVM dependent on a third party library > > * Makes LLVM platform support dependent on > > * Error handling in APR is somewhat strange and it could be quite > > difficult for us to continue to meet the "throw std::string" > > approach we have today. > > I vote against making LLVM dependent on even MORE things that we do not > control.Okay. Vote registered. :)> At least with the current system, we get to define the > interfaces, while putting in yet another tool, we are dependent on how > it does things.Just to be very clear, we would still control the *interface* just not the implementation. The lib/System headers would continue to exist, we just wouldn't have separate implementations of the functionality for each platform. Instead we'd use whatever small bits of APR were applicable to LLVM. No APR header file would be visible outside the implementation of lib/System.> > I think the complexity of being dependent on large external libraries > (APR, boost, et al) is enough of a downside to not incorporate them.Okay. -------------- 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/20040912/5fe1f874/attachment.sig>
On Sun, 12 Sep 2004, Reid Spencer wrote:> Our use of APR would be limited to the lib/System library. That is, we > would provide very thin C++ veneers on top of APR's C interface that > match the current lib/System and lib/Support APIs.I think that optionally supporting a an APR interface would not be a bad idea of obscure platforms, but LLVM should not depend on it. I think that all of the major platforms should be natively supported by lib/System. -Chris -- http://llvm.org/ http://nondot.org/sabre/
Hi everyone, On Sunday 12 September 2004 08:03 pm, Chris Lattner wrote:> > I think that all of the major platforms should be natively supported by > lib/System.They would, through the APR. Its not a major issue to me (and I'm a nobody here anyway), but I don't understand why you would insist on this software independence *now*, when LLVM is at a very early, and still largely unknown, stage. Note: I don't know anything about APR, so I'm not specifically endorsing it, just responding to the general idea that LLVM should be kept independent of everything. Note about Note: I would prefer you try to cover your dependencies using other C++ libs first (for no particular reason other than I'm biased towards C++), for example, boost probably has some things that we could use instead of APR (boost-filesystem, boost-signals, boost-threads), but of course, APR may have things you can't find anywhere else. In any event, what follows isn't specific to any particular lib. Use [insert-lib-here] to get up and running quickly on multiple platforms, and if the dependence issue becomes a problem later when LLVM becomes more popular, then come back and replace the [insert-lib-here]'s code. The point is to get LLVM up and running *now*, and get it out in the world so it'll start gathering mindshare, and more developers. Looking at Ocaml as an example, which is *roughly* equivalent to what LLVM is doing (bytecode compiler, native code compiler, virtual machine), except they built it for a specific language, they have numerous dependencies on other libs (curses, dbm, tcl, tk, etc). Python is also similar, and its base has dependencies on 6 other libs besides glibc, and that doesn't even count the add-on python modules (and what they depend on). If you want LLVM to become widespread and useful, you *will* end up either depending on other libraries or spending a lot of time reinventing the wheel. Your choice. :) FWIW, Ed