apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Apache Portable Runtime artifacts
Date Sun, 09 Nov 2008 18:28:25 GMT
Alan D. Cabrera wrote:

> I'm not sure that we need to choose one over the other.  Let me ask you 
> this, why would we need fine grained detail such as  "i386 vs. i586 vs. 
> i686"?  Is that really necessary?

It is, because code compiled for i686 won't run on an i386, and code 
written for i386 may not run as effectively as code for i686. One 
shouldn't make arbitrary restrictions on how specific the platform can be.

> I'm not sure why APR would allow such a system dependancy.  APR is 
> supposed to make application developers' lives easier.  Why would I have 
> to worry about libuuid1 missing?  I'm new to APR and am getting my head 
> around what it will and will not do for me.

A bit of history on APR and why it exists.

Way back when, when people tried to make Apache httpd portable to many 
platforms, the httpd code started getting filled up with endless #ifdefs 
that said "if this system do this, if that system do that".

To try and return some sanity, an effort was made to herd together all 
the non portable code in httpd into one single library. That library 
would offer some portable concepts like (for example) an apr_socket_t 
instead of an integer socket, and you would not have to care what 
platform you were on any more, you could just use sockets and take it 
for granted that they would "just work".

The library that resulted is APR.

Like the JVM itself, APR tries very hard to be portable across 
platforms, and to do this, it needs to know how that particular platform 
works so you don't have to.

APR makes your life easier because all you need to do is write code that 
depends on APR, and (within reason) you no longer have to care exactly 
how the particular functionality you are using works on that platform. 
Sockets work differently on Windows? You don't have to care.

The problem is that APR itself *does* have to care how the system works, 
and about details like libraries that may or may not be installed, so 
anybody wanting to package APR into a bundle is going to have to worry 
about these issues.

Imagine if you had to try and package up the JVM and include it in a 
maven repo, the problems you would face there are similar to the APR case.


View raw message